one connection for each request!

[ymajoros]

Hi there,

We migrated a big application from classic toplink to EJB 3, glassfish,
EclipseLink. Some big module is still using classic toplink queries for
a lot of things. As we didn't have the resource to change everything to
pure ejb & jpa, we tried a couple of "tricks". They kind of work (in
production), but I noticed that there is one connection for each db request.

It stills works fast enough, thanks to Glassfish connection pooling. But
I guess this is horrible. I also don't expect any

Here is how I get a UnitOfWork:

JpaEntityManager jpaEntityManager =
JpaHelper.getEntityManager(entityManager);
UnitOfWork unitOfWork = jpaEntityManager.getUnitOfWork();

Here is some eclipselink query which is causing thousand of db queries
_and_ acquiring about the same number of connections :

...
return ((Collection) unitOfWork.executeQuery(readAllQuery));

thx

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

[James Sutherland]

Read query's executed outside of a transaction use EclipseLink's readConnectionPool, so each query will use a read connection from the read pool.  This should not be an issue with internal or external connection pooling, and allows improved sharing of the connections and avoids transactional overhead for non-transactional read operations.

Why is a single readAllQuery triggering thousands of queries?  That is probably the bigger problem, consider using indirection/lazy, join fetching, or batch reading.

You can trigger the UnitOfWork to hold and use a single connection for its life-cycle using beginEarlyTransaction(), in JPA there is also an EclipseLink persistence unit option for using an exclusive connection.

ymajoros wrote:

Hi there,

We migrated a big application from classic toplink to EJB 3, glassfish,
EclipseLink. Some big module is still using classic toplink queries for
a lot of things. As we didn't have the resource to change everything to
pure ejb & jpa, we tried a couple of "tricks". They kind of work (in
production), but I noticed that there is one connection for each db request.

It stills works fast enough, thanks to Glassfish connection pooling. But
I guess this is horrible. I also don't expect any

Here is how I get a UnitOfWork:

JpaEntityManager jpaEntityManager =
JpaHelper.getEntityManager(entityManager);
UnitOfWork unitOfWork = jpaEntityManager.getUnitOfWork();

Here is some eclipselink query which is causing thousand of db queries
_and_ acquiring about the same number of connections :

...
return ((Collection) unitOfWork.executeQuery(readAllQuery));

thx