Re: Re: one connection for each request

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@...
Sybase, Inc

Yannick Majoros <yannick.majoros@...> Sent by: eclipselink-users-bounces@... 06/26/2009 01:45 PM Please respond to EclipseLink User Discussions <eclipselink-users@...>

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

Christopher.Mathrusse@... 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@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users



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