Re: one connection for each request

View: New views
8 Messages — Rating Filter:   Alert me  

Parent Message unknown Re: one connection for each request

by Reinhard Girstenbrei :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi Yannick,
the fact that 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. For sure you can get a ClientSession that obtains a connection and keeps it. You can also obtain an exlusive connection for read and write operations and keep it. But maybe the best solution is to use the connections lazily, the way you have observed EclipseLink to work.

Best regards,
Reinhard

see
http://wiki.eclipse.org/Configuring_a_Session_(ELUG)#Lazy_Connection_Acquisition


eclipselink-users-request@... wrote:
Send eclipselink-users mailing list submissions to
	eclipselink-users@...

To subscribe or unsubscribe via the World Wide Web, visit
	https://dev.eclipse.org/mailman/listinfo/eclipselink-users
or, via email, send a message with subject or body 'help' to
	eclipselink-users-request@...

You can reach the person managing the list at
	eclipselink-users-owner@...

When replying, please edit your Subject line so it is more specific
than "Re: Contents of eclipselink-users digest..."


Today's Topics:

   1. Re: Re: Cascade delete bug (221389) fixed in	2.0 line but not
      1.1 line? (Gordon Yorke)
   2. Can I persist a Map containing a List as Value (adi@...)
   3. Re: Can I persist a Map containing a List as Value (Tom Ware)
   4. Performance metrics...page down? (Laird Nelson)
   5. Re: Inserts and Caching (ossaert)
   6. one connection for each request! (Yannick Majoros)
   7. Debug Inner class (Ramesh.Ramasamy)
   8. Re: Debug Inner class (Tim Hollosy)
   9. Re: What options do I have for configuring auditing of
      Entities (Reinhard Girstenbrei) (Reinhard Girstenbrei)


----------------------------------------------------------------------

Message: 1
Date: Thu, 25 Jun 2009 10:36:57 -0300
From: Gordon Yorke gordon.yorke@...
Subject: Re: [eclipselink-users] Re: Cascade delete bug (221389) fixed
	in	2.0 line but not 1.1 line?
To: EclipseLink User Discussions eclipselink-users@...
Message-ID: 4A437D79.9020106@...
Content-Type: text/plain; charset="iso-8859-1"

This section of code is only entered when using 
UnidirectionalOneToManyMapping.  Please file a bug for the null pointer.
The bug report you mention (221389) was not included in 1.1.2 as the 
potential to destabilize that stream was considered to much for a 
maintenance release and the issue is easily resolved by manually 
performing the removes within the application.  If you absolutely need 
this functionality in the 1.1.X stream please reopen the bug with this 
information.
--Gordon

Russ Teabeault wrote:
  
Sorry.  I also forgot to mention that the problem we seem to have 
bumped into is a NullPointerException from the following in 
UnitOfWorkImpl.java

if(descriptor.hasMappingsPostCalculateChanges()) {
    int size = descriptor.getMappingsPostCalculateChangesOnDeleted().size();

...
  
It appears that the one map is being tested but a different map is 
being used.  This seems to have been fixed in trunk with r3826 and we 
are wondering the best way to resolve this in the 1.1 line.

Thanks,

Russell Teabeault

On Wed, Jun 24, 2009 at 4:08 PM, Russ Teabeault 
<rteabeault@... rteabeault@...> wrote:

    It seems that this cascade delete bug was fixed in the 2.0 line
    but not in the 1.1 line.  We uncovered this bug today and are
    wondering if there are plans for creating a 1.1.2 patch?

    ------------------------------------------------------------------------
    r3826 | gyorke | 2009-03-31 14:54:49 -0600 (Tue, 31 Mar 2009) | 4
    lines

    Cascade Delete bug  221389
    reviewed by James Sutherland, Andrei Ilitchev, Tom Ware

    Simple update missed during merge.
    ------------------------------------------------------------------------


------------------------------------------------------------------------

_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
  
    
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://dev.eclipse.org/mailman/private/eclipselink-users/attachments/20090625/428a4146/attachment.html

------------------------------

Message: 2
Date: Thu, 25 Jun 2009 16:33:22 +0200
From: adi@...
Subject: [eclipselink-users] Can I persist a Map containing a List as
	Value
To: eclipselink-users@...
Message-ID: 20090625163322.ayn1wasjz74s44g4@...
Content-Type: text/plain;	charset=ISO-8859-1

Hi

I persisted a map like this:
	private Map<String, String> instructions;

How can I persist a map that contains a List as value?
	private Map<String, List<String>> instructions;

Thanks a lot!

Regards Adrian



------------------------------

Message: 3
Date: Thu, 25 Jun 2009 10:42:51 -0400
From: Tom Ware tom.ware@...
Subject: Re: [eclipselink-users] Can I persist a Map containing a List
	as Value
To: EclipseLink User Discussions eclipselink-users@...
Message-ID: 4A438CEB.6080308@...
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

You will likely need an extra object to do this.  Something like:

private Map<String, ListHolder> instructions;

@Entity
public class ListHolder{
   @id
   private int id;

   private List instructions;

...
}

It should be pretty easy to write some business methods that make this mapping 
transparent to the users of the API.

-Tom

adi@... wrote:
  
Hi

I persisted a map like this:
	private Map<String, String> instructions;

How can I persist a map that contains a List as value?
	private Map<String, List<String>> instructions;

Thanks a lot!

Regards Adrian

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


------------------------------

Message: 4
Date: Thu, 25 Jun 2009 13:52:10 -0400
From: Laird Nelson ljnelson@...
Subject: [eclipselink-users] Performance metrics...page down?
To: EclipseLink User Discussions eclipselink-users@...
Message-ID:
	2c0ebf0c0906251052x35673626i11a1279e6222417b@...
Content-Type: text/plain; charset="iso-8859-1"

http://stame02.us.oracle.com/eclipselink/ is supposed to provide weekly
performance metrics on Oracle.  But it gives me a 404.  Where should I go
instead?

BEst,
Laird
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://dev.eclipse.org/mailman/private/eclipselink-users/attachments/20090625/55da469f/attachment.html

------------------------------

Message: 5
Date: Fri, 26 Jun 2009 00:27:25 -0700 (PDT)
From: ossaert decooman@...
Subject: Re: [eclipselink-users] Inserts and Caching
To: eclipselink-users@...
Message-ID: 24216103.post@...
Content-Type: text/plain; charset=us-ascii


Anyway, I still have the problem why the Insert over the API does not
work....

Can somebody help?

Thanks
Jan


  

--
Oracle
Reinhard Girstenbrei | Senior Principal Technical Support Engineer
Phone: +498914302318 | Mobile: +491775941318
Oracle Oracle Customer Service

ORACLE Deutschland GmbH | Riesstr. 25 | 80992 München


ORACLE Deutschland GmbH, Hauptverwaltung: Riesstraße 25, D-80992 München
Geschäftsführer: Jürgen Kunz, Registergericht: Amtsgericht München, HRB 82775
Green Oracle Oracle is committed to developing practices and products that help protect the environment



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

Re: Re: one connection for each request

by ymajoros :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Reinhard Girstenbrei a écrit :

>
> the fact that 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. For sure
> you can get a ClientSession that obtains a connection and keeps it.
> You can also obtain an exlusive connection for read and write
> operations and keep it. But maybe the best solution is to use the
> connections lazily, the way you have observed EclipseLink to work.
>
>
 Thank you for this information. But I still think something is wrong
and your advice could help me a lot.

 If there is a new connection for each db request, even if one single
query generates a lot of requests, I guess they won't use the same
transaction? I would like to have all request in a transaction.

 The EclipseLink queries are running in ejb session bean methods. I am
trying to get the transaction (UnitOfWork) which should be associated
with the injected EntityManager. Can I do this?

 Here are some stats from glassfish jdbc pool monitoring:

Resource Statistics (14) Name Value Details Description
NumConnSuccessfullyMatched 0 Count Last Sample Time: 26 juin 2009 14:38:49
Start Time: 26 juin 2009 11:43:10 Number of Connections successfully
matched
NumConnUsed 0 Count High Water Mark: 12 Count
Low Water Mark: 0 Count
Last Sample Time: 26 juin 2009 14:38:49
Start Time: 26 juin 2009 11:43:10 Provides Connection usage statistics.
In addition to number of connections being used currently, this also
provides information about the Maximum number of connections that were
used(High Watermark).
WaitQueueLength 0 Count Last Sample Time: 26 juin 2009 14:38:49
Start Time: 26 juin 2009 11:43:10 Provides a count value indicating the
number of connection requests in the queue waiting to be servied.
NumConnDestroyed 10 Count Last Sample Time: 26 juin 2009 14:38:49
Start Time: 26 juin 2009 11:43:10 Provides a count value reflecting the
number of connections that were destroyed since the last sampling
ConnRequestWaitTime 0 milliseconds High Water Mark: 16303 milliseconds
Low Water Mark: 0 milliseconds
Last Sample Time: 26 juin 2009 14:38:49
Start Time: 26 juin 2009 11:43:10 Provides a range value that indicates
the longest, shortest wait times of connection requests since the last
sampling. The current value indicates the wait time of the last request
that was serviced by the pool.
NumConnFailedValidation 0 Count Last Sample Time: 26 juin 2009 14:38:49
Start Time: 26 juin 2009 11:43:10 Provides a count value reflecting the
number of connections in the connection pool that failed validation
since the start time till the last sample time.
NumConnReleased 495643 Count Last Sample Time: 26 juin 2009 14:38:49
Start Time: 26 juin 2009 11:43:10 Provides a count value reflecting the
number of connections released back to the pool since the last sampling
NumConnFree 8 Count High Water Mark: 12 Count
Low Water Mark: 0 Count
Last Sample Time: 26 juin 2009 14:38:49
Start Time: 26 juin 2009 11:43:10 Provides a count value reflecting the
number of connections in the connection pool that are free as of the
last sampling
NumPotentialConnLeak 0 Count Last Sample Time: 26 juin 2009 14:38:49
Start Time: 26 juin 2009 11:43:10 Provides a count value reflecting the
number of potential connection leaks
AverageConnWaitTime 0 milliseconds Last Sample Time: 26 juin 2009 14:38:49
Start Time: 26 juin 2009 11:43:10 Average wait time-duration per
successful connection request
NumConnTimedOut 0 Count Last Sample Time: 26 juin 2009 14:38:49
Start Time: 26 juin 2009 11:43:10 Provides a count value reflecting the
number of connections in the connection pool that timed out since the
start time till the last sample time.
NumConnCreated 18 Count Last Sample Time: 26 juin 2009 14:38:49
Start Time: 26 juin 2009 11:43:10 Provides a count value reflecting the
number of connections that were created by the pool since the last
sampling.
NumConnAcquired 495643 Count Last Sample Time: 26 juin 2009 14:38:49
Start Time: 26 juin 2009 11:43:10 Provides a count value reflecting the
number of connections acquired from the pool since the last sampling
NumConnNotSuccessfullyMatched 0 Count Last Sample Time: 26 juin 2009
14:38:49
Start Time: 26 juin 2009 11:43:10 Number of Connections rejected during
matching


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

Re: Re: one connection for each request

by cmathrusse :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

There is a configuration on the Connection Pool in Glassfish that allows you to associated the connection to the current thread of execution. This will allow for the connection to be reused when it is requested. Take a look at the ConnectionPool and check this option.

Chris Mathrusse



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

06/26/2009 06:37 AM
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





Reinhard Girstenbrei a écrit :
>
> the fact that 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. For sure
> you can get a ClientSession that obtains a connection and keeps it.
> You can also obtain an exlusive connection for read and write
> operations and keep it. But maybe the best solution is to use the
> connections lazily, the way you have observed EclipseLink to work.
>
>
Thank you for this information. But I still think something is wrong
and your advice could help me a lot.

If there is a new connection for each db request, even if one single
query generates a lot of requests, I guess they won't use the same
transaction? I would like to have all request in a transaction.

The EclipseLink queries are running in ejb session bean methods. I am
trying to get the transaction (UnitOfWork) which should be associated
with the injected EntityManager. Can I do this?

Here are some stats from glassfish jdbc pool monitoring:

Resource Statistics (14) Name                  Value                  Details                  Description
NumConnSuccessfullyMatched                  0 Count                  Last Sample Time: 26 juin 2009 14:38:49
Start Time: 26 juin 2009 11:43:10                  Number of Connections successfully
matched
NumConnUsed                  0 Count                  High Water Mark: 12 Count
Low Water Mark: 0 Count
Last Sample Time: 26 juin 2009 14:38:49
Start Time: 26 juin 2009 11:43:10                  Provides Connection usage statistics.
In addition to number of connections being used currently, this also
provides information about the Maximum number of connections that were
used(High Watermark).
WaitQueueLength                  0 Count                  Last Sample Time: 26 juin 2009 14:38:49
Start Time: 26 juin 2009 11:43:10                  Provides a count value indicating the
number of connection requests in the queue waiting to be servied.
NumConnDestroyed                  10 Count                  Last Sample Time: 26 juin 2009 14:38:49
Start Time: 26 juin 2009 11:43:10                  Provides a count value reflecting the
number of connections that were destroyed since the last sampling
ConnRequestWaitTime                  0 milliseconds                  High Water Mark: 16303 milliseconds
Low Water Mark: 0 milliseconds
Last Sample Time: 26 juin 2009 14:38:49
Start Time: 26 juin 2009 11:43:10                  Provides a range value that indicates
the longest, shortest wait times of connection requests since the last
sampling. The current value indicates the wait time of the last request
that was serviced by the pool.
NumConnFailedValidation                  0 Count                  Last Sample Time: 26 juin 2009 14:38:49
Start Time: 26 juin 2009 11:43:10                  Provides a count value reflecting the
number of connections in the connection pool that failed validation
since the start time till the last sample time.
NumConnReleased                  495643 Count                  Last Sample Time: 26 juin 2009 14:38:49
Start Time: 26 juin 2009 11:43:10                  Provides a count value reflecting the
number of connections released back to the pool since the last sampling
NumConnFree                  8 Count                  High Water Mark: 12 Count
Low Water Mark: 0 Count
Last Sample Time: 26 juin 2009 14:38:49
Start Time: 26 juin 2009 11:43:10                  Provides a count value reflecting the
number of connections in the connection pool that are free as of the
last sampling
NumPotentialConnLeak                  0 Count                  Last Sample Time: 26 juin 2009 14:38:49
Start Time: 26 juin 2009 11:43:10                  Provides a count value reflecting the
number of potential connection leaks
AverageConnWaitTime                  0 milliseconds                  Last Sample Time: 26 juin 2009 14:38:49
Start Time: 26 juin 2009 11:43:10                  Average wait time-duration per
successful connection request
NumConnTimedOut                  0 Count                  Last Sample Time: 26 juin 2009 14:38:49
Start Time: 26 juin 2009 11:43:10                  Provides a count value reflecting the
number of connections in the connection pool that timed out since the
start time till the last sample time.
NumConnCreated                  18 Count                  Last Sample Time: 26 juin 2009 14:38:49
Start Time: 26 juin 2009 11:43:10                  Provides a count value reflecting the
number of connections that were created by the pool since the last
sampling.
NumConnAcquired                  495643 Count                  Last Sample Time: 26 juin 2009 14:38:49
Start Time: 26 juin 2009 11:43:10                  Provides a count value reflecting the
number of connections acquired from the pool since the last sampling
NumConnNotSuccessfullyMatched                  0 Count                  Last Sample Time: 26 juin 2009
14:38:49
Start Time: 26 juin 2009 11:43:10                  Number of Connections rejected during
matching


_______________________________________________
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

Re: Re: one connection for each request

by ymajoros :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Christopher.Mathrusse@... a écrit :
> There is a configuration on the Connection Pool in Glassfish that
> allows you to associated the connection to the current thread of
> execution. This will allow for the connection to be reused when it is
> requested. Take a look at the ConnectionPool and check this option.
>
I think the connections are reused: though connections seem to be
acquired a lot of times, there are only few actual new db connections.

 What I'd like to ensure is that all those queries, which are really
being made for the same use case, are in the same transaction. How to do
that?

 Perhaps I misunderstood and your suggestion could help us. Could you
tell us more details?

 Thanks,

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

Re: Re: one connection for each request

by cmathrusse :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


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.

Chris Mathrusse
christopher.mathrusse@...
Sybase, Inc



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

06/26/2009 08:58 AM
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 :
> There is a configuration on the Connection Pool in Glassfish that
> allows you to associated the connection to the current thread of
> execution. This will allow for the connection to be reused when it is
> requested. Take a look at the ConnectionPool and check this option.
>
I think the connections are reused: though connections seem to be
acquired a lot of times, there are only few actual new db connections.

What I'd like to ensure is that all those queries, which are really
being made for the same use case, are in the same transaction. How to do
that?

Perhaps I misunderstood and your suggestion could help us. Could you
tell us more details?

Thanks,

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

Re: Re: one connection for each request

by ymajoros :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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

Re: Re: one connection for each request

by cmathrusse :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


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

Parent Message unknown Re: one connection for each request

by Reinhard Girstenbrei :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi Yannick,
the persistence.xml allows to configure a jta-datasource and a
non-jta-datasource.
A possible option is to configure the non-jta-datasource for a
connection pool configuration configured for local transactions.
Non-transactional operations like SELECT statements would be executed
using connections obtained by such non-jta-datasource.
EclipseLink defers write operations by default. All necessary DML
statements will be executed when beforeCompletion() is called by the
transaction service.
The DML statements will be executed using a connection taken from the
jta-datasource.
Typically it more important to share a connection object more
efficiently than to take advantage of keeping affinity of a session or
transaction to a connection.
One reason might by that a session or transaction is repeatedly calling
the very same statement and therefore using the statement cache of a
connection object might have some value.
But do not overestimate the advantage of a statement cache.

As I have stated before the default behavior of EclipseLink is the best
choice in most cases.
Anyway you can also configure eager connections instead of lazy
connections, and you can configure an exclusive connection mode which
allows to use the write connection for reading.
In this case you have to consider transaction isolation and it's impact
on the shared cache.

If you have a support contract for Oracle Application Server, WebLogic
Server or TopLink you can open a service request to discuss your
specific case.

Best regards,
Reinhard

eclipselink-users-request@... wrote:

> Send eclipselink-users mailing list submissions to
> eclipselink-users@...
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
> or, via email, send a message with subject or body 'help' to
> eclipselink-users-request@...
>
> You can reach the person managing the list at
> eclipselink-users-owner@...
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of eclipselink-users digest..."
>
>
> Today's Topics:
>
>    1. Re: Query using WHERE - IN on a Join Table Question (sonavor)
>    2. Re: Re: one connection for each request (Yannick Majoros)
>    3. Re: Re: one connection for each request
>       (Christopher.Mathrusse@...)
>    4. MySQL batch delete bug (211084) - why so low priority?
>       (Tobias Marklund)
>    5. Expression for all lineitems that where picked today
>       (Philipp Kursawe)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 26 Jun 2009 12:53:24 -0700 (PDT)
> From: sonavor <jw@...>
> Subject: Re: [eclipselink-users] Query using WHERE - IN on a Join
> Table Question
> To: eclipselink-users@...
> Message-ID: <24226373.post@...>
> Content-Type: text/plain; charset=us-ascii
>
>
> Thanks for the information Chris.  
>
> I did try a few tests with the EclipseLink ExpressionBuilder.  I was able to
> get that to work with a ReadAllQuery but I still had to build the expression
> where I am do "OR" operations between the conditions -
>
>      Expression exp = null;
>      ExpressionBuilder eb = new ExpressionBuilder(TestListing.class);
>      for ( Iterator it=kwList.iterator();it.hasNext(); ) {
>             TestKeywords tkw = (TestKeywords)it.next();
>             Expression expKw =
> eb.anyOf("testKeywordsCollection").equal(tkw);
>             if ( exp == null ) {
>                 exp = expKw;
>             } else {
>                 exp = exp.or(expKw);
>             }
>       }
>      
>        ReadAllQuery readAllQuery = new ReadAllQuery(TestListing.class);
>        readAllQuery.setSelectionCriteria(exp);
>
> ...then get the ActiveSession from the EntityManager and run the query...
>
> I think I will go with the EntityManager.createQuery where I build up the
> "OR" operator on the submitted keyword Id values for now.
>
> When EclipseLink 2.0 is available I will retry the "IN" operation.  I don't
> see a download for EclipseLink 2.0 on the web site.
>
>
>
> Christopher Delahunt wrote:
>  
>> Hello,
>>
>> IN is supported, but in JPA 1.0, IN cannot take a collection as a
>> parameter which is why you get an exception.
>>
>> EclipseLink native expressions have always allowed taking a collection
>> as a parameter if you are able to build your query that way instead, or
>> if you can upgrade, support was just added to EclipseLink 2.0 so that
>> JPQL will also allow taking the collection and is in the more recent
>> nightly builds (added 2009-06-10 through bug 249224)..
>>
>> Best Regards,
>> Chris
>>
>> sonavor wrote:
>>    
>>> I am using Eclipselink and have three tables I am testing.  I am
>>> experimenting with have a many-to-many relationship between a main,
>>> listing
>>> table and a keyword table.
>>> The database is MySql.
>>>
>>> One table is called TEST_LISTING with these columns -
>>> LISTING_ID integer (PK)
>>> LISTING_NAME varchar(40)
>>>
>>> Second table is called TEST_KEYWORDS with these columns -
>>> KW_ID integer (PK)
>>> KW_NAME varchar(24)
>>>
>>> Third table is a join table called KW_MAP with these columns -
>>> LISTING_ID integer  (PK)
>>> KW_ID integer         (PK)
>>>
>>> So, using Netbeans 6.1, I generated two JPA entity classes -
>>> TestListing.java
>>> TestKeywords.java
>>>
>>> that have a many-to-many relationship to each other via the KW_MAP table.
>>>
>>> This all works and I can use a join query like this -
>>>
>>> My method receives an ArrayList of Integer values that are the Id of
>>> selected TEST_KEYWORDS called tkwIdArray.
>>>
>>>         StringBuffer qSB = new StringBuffer();
>>>         qSB.append("SELECT t FROM TestListing as t ");
>>>         qSB.append("JOIN t.testKeywordsCollection as tkw ");
>>>         qSB.append("WHERE ");
>>>        
>>>         for ( int i=0;i<tkwIdArray.length;i++ ) {
>>>             Integer tkid = tkwIdArray[i];
>>>             if ( i == 0 ) {
>>>                 qSB.append("tkw.kwId =
>>> :arg").append(String.valueOf(i)).append(" ");
>>>             } else {
>>>                 qSB.append("OR tkw.kwId =
>>> :arg").append(String.valueOf(i)).append(" ");
>>>             }
>>>         }
>>>          
>>>         Query q = em.createQuery(qSB.toString());
>>>         for ( int i=0;i<tkwIdArray.length;i++ ) {
>>>            q.setParameter("arg"+String.valueOf(i), tkwIdArray[i]);
>>>         }
>>>      
>>>         List<TestListing> tList = q.getResultList();
>>>
>>> Although that works I would like to create the query where it looks more
>>> simple by using "IN"
>>>
>>> I tried this -
>>>
>>> I create a List<Integer> named "idList" that is an ArrayList of the
>>> submitted TEST_KEYWORDS Id values.
>>>
>>> List<TestListing> tList = em.createQuery("SELECT t FROM TestListing as t
>>> JOIN t.testKeywordsCollection as tkw WHERE tkw.kwId IN (?1)")
>>>                                         .setParameter(1,
>>> idList).getResultList();
>>>
>>> When I try this query I get -
>>>
>>> java.lang.IllegalArgumentException: You have attempted to set a value of
>>> type class java.util.ArrayList for parameter 1 with expected type of
>>> class
>>> java.lang.Integer from query string SELECT t FROM TestListing as t JOIN
>>> t.testKeywordsCollection as tkw WHERE tkw.kwId IN (?1).
>>>
>>> Does Eclipselink not support using the "IN" attribute in a query?
>>>
>>> As a different kind of test I rewrote the join query to find TEST_LISTING
>>> records by joining on the TEST_KEYWORDS.KW_NAME column so I could try the
>>> "IN" with a String Array.  I can get the "IN" to work with a hard-coded
>>> String array like -
>>>
>>> List<TestListing> tList = em.createQuery("SELECT t FROM TestListing as t
>>> JOIN t.testKeywordsCollection as tkw WHERE tkw.kwName IN
>>> ('italian','food')").getResultList();
>>>
>>> but when I change it to this -
>>>
>>> List<String> kwnList = new ArrayList<String>();
>>>         kwnList.add("italian");
>>>         kwnList.add("food");
>>>         List<TestListing> tList = em.createQuery("SELECT t FROM
>>> TestListing
>>> as t JOIN t.testKeywordsCollection as tkw WHERE tkw.kwName IN (?1)")
>>>                  .setParameter(1, kwnList).getResultList();
>>>
>>> I get the error -
>>> java.lang.IllegalArgumentException: You have attempted to set a value of
>>> type class java.util.ArrayList for parameter 1 with expected type of
>>> class
>>> java.lang.String from query string SELECT t FROM TestListing as t JOIN
>>> t.testKeywordsCollection as tkw WHERE tkw.kwName IN (?1)
>>>
>>> Is there a way to do this using Eclipselink or should I just stick with
>>> my
>>> iteration construction of the query using "OR" clauses?
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>  
>>>      
>> _______________________________________________
>> 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