• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

releasing connection in CMT

 
Ranch Hand
Posts: 106
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 106
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 19
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 106
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 19
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Ranch Hand
Posts: 489
Eclipse IDE Tomcat Server Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 106
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Sheriff
Posts: 10445
227
IntelliJ IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Babji Reddy
Ranch Hand
Posts: 106
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Sheriff
Posts: 10445
227
IntelliJ IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes.
 
Babji Reddy
Ranch Hand
Posts: 106
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 489
Eclipse IDE Tomcat Server Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
>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
Sheriff
Posts: 10445
227
IntelliJ IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 106
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 489
Eclipse IDE Tomcat Server Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 106
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks all for the clarifications.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic