Re: [eclipselink-users] Re: one connection for each request

[Christopher.Mathrusse@xxxxxxxxxx]

As Reinhard pointed out: 
"each
query obtains it's own connection is intended behavior. This does guarantee
that the application holds on a connection for the minimum amount of time
and therefore it allows the most efficient use of precious physical connection
resources."

You don't really need to worry about
the EM holding onto the connection. The fact is that the all work performed
within a transaction is a unit of work. It doesn't matter if it is one
connection or 10. All resources enlisted within the transaction will get
committed when the transaction is committed. 

I'm guessing that in your persistence.xml
file you supplied a JNDI name to your DataSource. Something like:
        <jta-data-source>jdbc/myDataSource</jta-data-source>

That allows the EM to locate the DataSource
and acquire a connection whenever it is needed. It doesn't mean that it
should hold on to it as long as the session is active. Seeing as the container
is managing your transactions it is far more efficient to not hold onto
the connection and simply let the container do its job. By configuring
the ConnectionPool to associate the connections with the running thread
it will be guaranteed that you will always use the same connection, from
the connection pool, during the running transaction. So in essence, you
really don't need to worry about it.

If you want to see the transaction boundaries,
when the tx is started and committed, you only need to enable logging for
those services. Locate the logging levels tab in the GlassFish admin console
either by selecting the application server from the tree menu (if you are
a stand alone server) or by expanding the cluster and selecting logger
settings (if your server is a cluster). On the Logging Levels tab you will
see all of the services available for logging, including any custom ones
that you have added, at the bottom of the page.  Simply set the level
to FINE, FINER or FINEST for the JTA and JTS services. This will allow
you to see all activity transpiring.


Chris Mathrusse
christopher.mathrusse@xxxxxxxxxx
Sybase, Inc

Yannick Majoros <yannick.majoros@xxxxxxxxxxxx>
Sent by: eclipselink-users-bounces@xxxxxxxxxxx

06/26/2009 01:45 PM

Please respond to
EclipseLink User Discussions <eclipselink-users@xxxxxxxxxxx>

To	EclipseLink User Discussions <eclipselink-users@xxxxxxxxxxx>
cc
Subject	Re: [eclipselink-users] Re: one connection for each request

Christopher.Mathrusse@xxxxxxxxxx a écrit :
>
> GlassFish is managing your connection pool and Transactions. (or it
> should be) So long as you have your transaction boundaries defined
on 
> your EJB's a transaction should be started for you by the container
on 
> each method invocation. Even if you don't explicitly define a 
> transaction boundary with the @Transaction annotation, the containers
> default behavior is to start a transaction on method invocation of
the 
> EJB. So a transaction should be started if one doesn't exist. The
> enlistment of the connection within the transaction is handled by
the 
> container as it is managing the connection pool. Every time a 
> connection is retrieved from the pool, it will be enlisted within
the 
> running transaction. (Unless you explicitly suspend the running 
> transaction)
>
> The connection pool has configuration options. As I stated, one is
for 
> associating the connection to the running thread of execution. This
> allows the connection to be reused each time a connection is requested
> by the thread. Another configuration of the pool is to allow 
> non-transactional connections, which allows callers that are not 
> within a transaction to retrieve a connection from the pool. This
> option should *_not _*be checked and will cause an exception to be
> thrown if a non-transactional caller requests a connection. So 
> basically, if it is unchecked and your are retrieving connections
from 
> the pool and no exception is thrown, then all connections are 
> operating within a running transaction.
>
> I hope this helps clarify.
>
 Ok, I think I understand your point. So, it seems everything is ok and
I don't need to worry, right? Is there a way to "see" the effective
transaction boundaries? I mean, can I find out which requests where 
executed in what transaction?

 I thought that for an ejb-managed EntityManager, there was a client 
session, and so the EntityManager should keep its connection while it is
alive. Is this wrong?

 Thanks for your advice,

Yannick
_______________________________________________
eclipselink-users mailing list
eclipselink-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-users