| Scenario I: |
| tx { |
| Bean1 -> getConnection -> insert data into table -> call bean2 -> close connection |
| Bean2 -> getConnection -> update above data -> close connection |
| } |
| |
| tx { |
| Bean1 -> new transaction query that data indeed got updated |
| } |
| --- |
| |
| Scenario II: |
| tx { |
| Bean1 -> getConnection -> insert data into table -> close connection -> call bean2 |
| Bean2 -> getConnection -> update above data --> close connection |
| } |
| |
| tx { |
| Bean1 -> new transaction query that data indeed got updated |
| } |
| --- |
| |
| Scenario III: |
| tx { |
| Bean1 -> getConnection:c1 -> insert data into table -> getConnection:c2 |
| -> insert some more data -> call bean2 -> close c1, c2 |
| Bean2 -> getConnection -> update above data --> close connection |
| } |
| |
| tx { |
| Bean1 -> new transaction query that data indeed got updated |
| } |
| --- |
| |
| Scenario IV: |
| tx { |
| Bean1 -> getConnection:c1 -> insert data into table -> getConnection:c2 |
| -> insert some more data -> close c1,c2 -> call bean2 |
| Bean2 -> getConnection -> update above data --> close connection |
| } |
| |
| tx { |
| Bean1 -> new transaction query that data indeed got updated |
| } |
| |
| Adding a test-case (test7 in EJB) for GlassFish-Issue : 15443 |
| Two resource-refs (in this case @Resource injections) for same resource |
| and doing a physical lookup of same resource (initialContext.lookup), which was failing. |
| Fix for 15443 should make this test pass. |
| |
| Adding a test-case (test8 in EJB) for GlassFish-Issue : 15577 or 15586 |
| Two resources from two different pools (each one with different database, assoc-with-thread=true) |
| to make sure that connections from approrpiate pool is retrieved from the thread-local. |
