Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-dev] EntityManager usage of ClientSession

1. I was wrong, we only release RepeatableWriteUOW and its parent ClientSession in case either transaction rolled back or clear method was called on the em.
However the important point is that the life spans of both uow and its parent ClientSession are the same.
The properties (passed to createEntityManager method) are kept by EntityManager, so they are re-used in case the new uow created (after rollback or clear).
I think jpa pa support should be done on top of fixing https://bug.oraclecorp.com/pls/bug/webbug_edit.edit_info_top?rptno=5929727 - to get rid of all events the user otherwise has to handle.
 
----- Original Message -----
Sent: Wednesday, February 20, 2008 4:18 PM
Subject: RE: [eclipselink-dev] EntityManager usage of ClientSession

Andrei,
 
Thanks for getting back to me. I have one additional question below.
 
Doug
-----Original Message-----
From: eclipselink-dev-bounces@xxxxxxxxxxx [mailto:eclipselink-dev-bounces@xxxxxxxxxxx]On Behalf Of Andrei Ilitchev
Sent: Wednesday, February 20, 2008 10:02 AM
To: Eclipselink-Dev (E-mail)
Subject: Re: [eclipselink-dev] EntityManager usage of ClientSession

>1. Should our EntityManagerImpl wrap a client-session instead of a server session to better handle the isolated client session's cache lifecycle matching that of the EntityManager? If we need a server session we can always get it through getParent()
The ClientSession is released after JTA transction is completed, therefore we can't keep ClientSession for the lifetime EntityManagerImpl.

[Doug Clarke] Why is this? If I decide I want to use just the shared cache it continues to function across multiple EntityManager and across multiple transactions within those entity managers. Why is it then why I decide I want an isolated cache would that cache not live for the lifespan of my EntityManager across zero or more transactions. I can see how the UnitOfWork used in the EntityManager would be released after the commit.
 
Note: We would need to discuss how EntityManager.clear() would behave with respect to the client sessions's isolated cache versus the transactional cache and an extended persistence context.
 
 
>2. How can we address proxy authentication through JPA? We need to change how we create the client session within the EntityManagerImpl and thus the lifecycle of the client session is important to this discussion. See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=219434
 
We should pass proxy authentication properties to createEntityManager method, then use thiese properties in to create first ClientSession, then RepeatableWriteUOW in getActivePersistenceContext method.
 
>3. Does anyone have an idea of how I could work-around our current implementation limitations to make proxy authentication work through our current JPA implementation in EclipseLink?
It *might* be possible to do something probably using thread variables.

[Doug Clarke] OK, thanks. I'll try a few things out. 
----- Original Message -----
Sent: Wednesday, February 20, 2008 8:37 AM
Subject: [eclipselink-dev] EntityManager usage of ClientSession

Developers,
 
On the TopLink forum there is a customer trying to use proxy authentication. Our documentation and a similar thread on the JDeveloper forum show the usage of proxy authentication using a SessionEventListener and a custom call to Server.acquireClientSession(db-login). Using this within JPA is proving challenging. The SessionEventListener can be easily introduced using a persistence unit property but addressing the proxy credentials is more challenging:
        Login login = (Login)serverSession.getLogin().clone();
        
        login.setProperty("proxytype", Integer.toString(OracleConnection.PROXYTYPE_USER_NAME)); 
        login.setProperty(OracleConnection.PROXY_USER_NAME, "hr"); 
        ConnectionPolicy connectionPolicy = new ConnectionPolicy(login);
        // for vpd support connectionPolicy.setShouldUseExclusiveConnection(true);    
       
        clientSession =  serverSession.acquireClientSession(connectionPolicy);
I took a quick look through our implementation of EntityManager and we have one case where we acquire a client session in the process of acquiring a UnitOfWork but in most cases we simply acquire the UnitOfWork from the server session. I know this internally results in a client session but it does feel weird. I would have expected us to acquire a client session and hold it in the EntityManager (possibly during construction) and then acquire repeatable-read UnitOfWork or non-synchonized UnitOfWork as needed form the client session. This would allow the isolated client session, when used, to have a life-cycle equivalent to that of the EntityManager.
 
I guess I have a few questions:
 
1. Should our EntityManagerImpl wrap a client-session instead of a server session to better handle the isolated client session's cache lifecycle matching that of the EntityManager? If we need a server session we can always get it through getParent()
 
2. How can we address proxy authentication through JPA? We need to change how we create the client session within the EntityManagerImpl and thus the lifecycle of the client session is important to this discussion. See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=219434
 
3. Does anyone have an idea of how I could work-around our current implementation limitations to make proxy authentication work through our current JPA implementation in EclipseLink?
 
Cheers,
 
Doug
 
Oracle Email Signature Logo
Doug Clarke
Director of Product Management, Oracle TopLink 
Oracle Server Technologies
45 O'Connor, Suite 4000 | Ottawa, ON  K1P 1A4 Canada
+1 613 288 4617
 


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


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

Back to the top