GeeCON Prague 2014*
The moose likes EJB and other Java EE Technologies and the fly likes releasing connection in CMT Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "releasing connection in CMT" Watch "releasing connection in CMT" New topic
Author

releasing connection in CMT

Babji Reddy
Ranch Hand

Joined: Jan 24, 2006
Posts: 106
Hi if I use a stateless session bean that uses Container Managed Transactions, lets say the flow of the ejb method is
(1) obtains connection from pool
(2) does some CRUD operations with database using simple JDBC statements
(3) Takes the data obtained and be in a compuation algorithm
(4) does some more CRUD with database
(5) releases connection

Now if the step 3 is taking a while. Is there any room for optimation by releasing the connection before 3, and reobtain one after 3. If I do this does the CRUDs in 2 and 4 are treated as same atomic transaction by the EJB container?
Phani Raju
Greenhorn

Joined: Aug 03, 2007
Posts: 19
When you are using CMT, the container has no way to know when the transaction is complete untill the business method is completed either successfully/by throwing an exception. So it will keep the used connection aside and will reuse it, which implies all the operations shall be part of same transaction.
Babji Reddy
Ranch Hand

Joined: Jan 24, 2006
Posts: 106
Hi Phani
Can you please elaborate more.
So it will keep the used connection aside and will reuse it
. Who is the 'it' here? Is it the EJB container?
And are you implying that yes the connection can be returned to pool and get another connection later with in the same EJB method and the container will still honor the database operations done on two different connections as one transaction?
Phani Raju
Greenhorn

Joined: Aug 03, 2007
Posts: 19
Yes, the EJB container shall keep the connection aside till the business method execution is over and will give the same connection back again if requested. See, I might be saying that the container shall keep the connection aside, but a different implementation may actually put in back to the pool and mark it as locked so that another thread cannot use this connection.

So in the case you mentioned, the container will be giving the same connection back again and again so it can manage the changes to database (done at different times, but in the same business method) as part of single transaction.
Babji Reddy
Ranch Hand

Joined: Jan 24, 2006
Posts: 106
That doesn't seem right.
If the same connection is needed back by the container for some other database operations within the same EJB method, then why would the conainer need to take an extra step of 'keeping the connection aside', because the connection as such is already in used/locked state.

Guess So far the anwer to my question is "No, you cannot release the connection and have it used by somebody else, and the same EJB method pick up another connection from pool".

Any other insight, guys.
Phani Raju
Greenhorn

Joined: Aug 03, 2007
Posts: 19
That doesn't seem right.
If the same connection is needed back by the container for some other database operations within the same EJB method, then why would the conainer need to take an extra step of 'keeping the connection aside', because the connection as such is already in used/locked state.


I said container shall keep the connection aside as reply to your question where in you mentioned about releasing the connection before executing computational logic and obtain the connection again.
ramprasad madathil
Ranch Hand

Joined: Jan 24, 2005
Posts: 489

If the same connection is needed back by the container for some other database operations within the same EJB method, then why would the conainer need to take an extra step of 'keeping the connection aside', because the connection as such is already in used/locked state.


Because you called close() on it. Think about it - each time you obtain a connection (say in dao1 and dao2 etc), would you wait for the transaction to complete before calling close() on each connection? N0 - you would obtain the connection, do some operation and close it. It is the function of the datasource to identify that the connection is used in a transaction and probably return the same connection object for your next call for getConnection() in dao2. That's what the container is for.

Phani is right.

ram.
Babji Reddy
Ranch Hand

Joined: Jan 24, 2006
Posts: 106
Ram, thats exactly where my question is. You said
connection is used in a transaction and probably return the same connection object for your next call for getConnection() in dao2
.

Is it probably the same connection or always the same connection.

(1)If its probably same connection, which means the second dao is getting a different connection (under the same transaction), and hence the EJB's transaction manager is handiling the transaction that involves two different connections. Is this right?
And then In such case why would container have to do any thing special with the first connection (like keeping aside or lokced state), because by keeping the previously closed connection its wasting first connection. If the reason for keeping it aside/locked is to gather the associate the transaction data from the connection, then why would dao2 waste another connection instead of using the first connection.

(2) always the same connection doesn't seem right anyways.
Jaikiran Pai
Marshal

Joined: Jul 20, 2005
Posts: 10146
    
165

A close() on the connection returns the connection to the pool. Once the connection is returned to the pool, it's in a ready to use state. Any (waiting/subsequent) requests to the datasource for a connection can end up using this ready to use connection.

[My Blog] [JavaRanch Journal]
Babji Reddy
Ranch Hand

Joined: Jan 24, 2006
Posts: 106
Agree. So if within an EJB method two different connections are used, the EJB's transaction manager can commit/rollback the details touched by both of the connections. right?
Jaikiran Pai
Marshal

Joined: Jul 20, 2005
Posts: 10146
    
165

Yes.
Babji Reddy
Ranch Hand

Joined: Jan 24, 2006
Posts: 106
phew. thanks much for the clarification.

This means the transaction manager manages the 'transaction data' of each connection independent of each connection 'some where' and able to grab them at the end of the method to process commit / rollback.
And that's probably why the savepoint is not available in 'user transaction' API also, but just is in the connection object.

Can you suggest any reading to delve deep into this area.
ramprasad madathil
Ranch Hand

Joined: Jan 24, 2005
Posts: 489

>always the same connection doesn't seem right anyways.

Whats the problem with that?

> close() on the connection returns the connection to the pool. Once the connection is returned to the pool, it's in a ready to use state. Any (waiting/subsequent) requests to the datasource for a connection can end up using this ready to use connection.

I think that depends on whether the connection is in the scope of a transaction. It further depends on whether the tx is XA or non-XA.

>This means the transaction manager manages the 'transaction data' of each connection independent of each connection 'some where' and able to grab them at the end of the method to process commit / rollback.

I really think it shouldnt matter to an application developer. You use a connection, call close() on it and commit later and leave it to the transaction manager to implement it in the best way fit.

It is dangerous to make this kind of sweeping common assumptions especially when it is left to the vendor to implement it in whateverfashion provided the end points meet.

If it's for the sake of an argument or proof, here's how Weblogic does it (from weblogic docs - http://download-llnw.oracle.com/docs/cd/E13222_01/wls/docs103/jdbc_admin/jdbc_datasources.html)

Please note the quotes in bold where it specifies that it uses the same underlying connection object

With an EJB architecture, it is common for multiple EJBs that are doing database work to be invoked as part of a single transaction. Without XA, the only way for this to work is if all transaction participants use the exact same database connection. When you enable global transactions and select either Logging Last Resource or Emulate Two-Phase Commit, WebLogic Server internally uses the JTS driver to make sure all EJBs use the same database connection within the same transaction context without requiring you to explicitly pass the connection from EJB to EJB.
If multiple EJBs are participating in a transaction and you do not use an XA JDBC driver for database connections, configure a Data Source with the following options:

Supports Global Transactions selected
Logging Last Resource or Emulate Two-Phase Commit selected
This configuration will force the JTS driver to internally use the same database connection for all database work within the same transaction.


I think its the same with websphere and I dont know about JBoss or even with Spring Tx Manager. However it comes back to the point that it is an internal implementation of the container. Returning to the original question of optimization, the best and only possible thing to do is return the connection back to the pool after use. The container will do the optimization for you.

ram.








Jaikiran Pai
Marshal

Joined: Jul 20, 2005
Posts: 10146
    
165

ramprasad madathil wrote:

> close() on the connection returns the connection to the pool. Once the connection is returned to the pool, it's in a ready to use state. Any (waiting/subsequent) requests to the datasource for a connection can end up using this ready to use connection.

I think that depends on whether the connection is in the scope of a transaction. It further depends on whether the tx is XA or non-XA.


I admit, my statement was specific to the way JBoss does it.
Babji Reddy
Ranch Hand

Joined: Jan 24, 2006
Posts: 106
in the Weblogic's description the bold text came with a precondition too that it needs certain Weblogic configuration params to be set.
So it means your design/code has to know what App server its going to be

To answer the pool giving always the same connection, if the spec lays out that connection pool should always give the same connection, and hence it cannot be given to others when not in use between the DAOs of the same EJB and hence its not worth spending time in closing it and reopening it and hence questions the DAO pattern.

The usage of same/different connection is based on XA/non-XA transaction, which is one of the reasons for this post. Ideally transaction manager should have configure-ability
to let it know that all the different involved DAOs use the same database and hence no need to take the overhead of two phase commit, but try to gather transaction data from various connections.

ramprasad madathil
Ranch Hand

Joined: Jan 24, 2005
Posts: 489

in the Weblogic's description the bold text came with a precondition too that it needs certain Weblogic configuration params to be set.
So it means your design/code has to know what App server its going to be


That's always the case - configuring data source and many other entities (servers, jms modules etc) are all very server specific. There is no spec around it. I doubt if it is possible to create and deploy an enterprise application w/o it being aware of the server on which it is deployed.

To answer the pool giving always the same connection, if the spec lays out that connection pool should always give the same connection, and hence it cannot be given to others when not in use between the DAOs of the same EJB and hence its not worth spending time in closing it and reopening it and hence questions the DAO pattern.


The Datasource api (if that's what is referred to as the spec) does not define behaviour in such cases. Take a look at http://java.sun.com/j2se/1.4.2/docs/guide/jdbc/getstart/datasource.html

I dont have anything more to add on this topic

ram.
Babji Reddy
Ranch Hand

Joined: Jan 24, 2006
Posts: 106
Thanks all for the clarifications.
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: releasing connection in CMT