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.