The blogs explains how JCA connection management works in WebSphere Application server. It's important to understand transactions and connection sharing basic before you deep dive into the connection behavior.
- A transaction groups pieces of work that should be atomic (all or nothing). If any piece of the transactional work fails, the entire transaction will roll back.
- Resource managers include relational databases (JDBC™ data source), messaging systems (JMS), Enterprise Information Systems (EIS)
- Resource Manager can support two types of transactions:
- Global Transaction context:
A global transaction is also referred to as a distributed transaction, an XA transaction, a 2PC (2-phase commit) transaction, or just a transaction. This type of transaction is global, or distributed, in the sense that multiple resource managers may be accessed within the transaction and the transaction manager has the ability to coordinate among all the resource managers to ensure the atomicity of update
- Local transaction containment:
An application which operates outside of a global transaction will execute instead under an "unspecified" transaction context. WebSphere defines this as LTC. The LTC is created automatically by WebSphere Application server when the Global Transaction is not defined in the application or created by the container.
Shared Connection :
UnShared Connection :
- Same connection can be re-used within the Transaction scope. When the application executing in an LTC closes the connection, the connection will not be returned to the free pool, unless the current LTC has ended.
- Unshareable connections are not shared in LTC and have no LTC affinity. When the application executing in an LTC closes the connection, the connection is immediately returned to the free pool, even though the current LTC has not ended.
1. Image explains when to use Shared Connection and Unshared connections in LTC and Global transaction.
Note: Global Transaction is automatically created in Container Managed EJB and when the UserTransaction API is called in Servlet, MDB and Bean Managed EJB.
2. Image explains how the unshared connection works in LTC. Each and every getConnection request, receive a separate connection handle(managed physical connections) . 1:1 ratio.
3. Image explains how the shared connection works in LTC (Bad Programming). If you don't write the code properly *get/use/close) then there is more disadvantage than an advantage using shared connection in LTC. One manged connection per a getConnection request. You should avoid this behavior.
4. Image explains how the shared connection works in LTC (Good Programming). When you follow serial re-use, the connections are shared
5. Image explains how the shared connection works in Global Transaction. In GT, the connections are handled by the transaction. Connections are shared by default but its always a good practice to follow serial re-use (get/use/close)
6. Image explains when the connection will be closed in LTC
7. Image explains when the connection will be closed in Global Transaction
Follow the basic get/use/close pattern to avoid Connection Leak issues.