db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: [DISCUSS] getPersistenceManagerProxy
Date Sun, 11 Feb 2007 20:58:49 GMT
Hi Dain,

Thanks for your comments. These rules are intended to be identical to  
the JPA semantics.  One intended side effect is that the container  
can simply make the PMF call to get a proxy in order to inject a PM  
into a component. Of course, container injection behavior is not  
specified for JDO :-( but this would make it easier.

Craig

On Feb 11, 2007, at 10:15 AM, Dain Sundstrom wrote:

> Sounds exactly like the JPA rules, so it makes sense to me.  If  
> there are supposed to be differences in comparison to the JPA  
> rules, I suggest you explicitly call them out due the the extreme  
> similarity between the two in this text.
>
> -dain
>
> On Feb 9, 2007, at 2:00 PM, Craig L Russell wrote:
>
>> Please review and comment on this proposed change to the  
>> specification, as part of the JDO 2.1 maintenance release.
>>
>> <proposal>
>> (PersistenceManagerFactory interface)
>> 11.3.1 Access via proxy
>> PersistenceManager getPersistenceManagerProxy();
>> Returns a PersistenceManager instance that is thread-safe, for use  
>> in web and application servers and outside servers. The instance  
>> returned can be used in a servlet init method to initialize a  
>> static variable in a web server application. Similarly, it can be  
>> used in a session bean to initialize a static variable in an  
>> application server application.
>>
>> If this method is used with a PersistenceManagerFactory that is  
>> configured with TransactionType JTA, the proxy returned will  
>> dynamically delegate to a PersistenceManager. The close method on  
>> the proxy has no effect.
>> o If there is a PersistenceManager currently associated with the  
>> thread’s transaction, the method in the proxy delegates to the  
>> corresponding method in the PersistenceManager currently  
>> associated with the thread’s transaction.
>> o If there is no PersistenceManager currently associated with the  
>> thread’s transaction, a PersistenceManager is created and  
>> associated with the thread’s transaction.
>> o If there is no transaction currently associated with the calling  
>> thread, a new PersistenceManager is created with no transaction  
>> association, and no possibility of beginning a transaction (in  
>> this case, the begin method on the Transaction instance throws  
>> JDOUserException). Persistent instances returned as a result of  
>> queries can be used to navigate via nontransactional access,  
>> regardless of whether a transaction is subsequently associated  
>> with the thread. The PersistenceManager returned from methods  
>> Query.getPersistenceManager, JDOHelper.getPersistenceManager, and  
>> PersistenceCapable.getPersistenceManager return the actual  
>> PersistenceManager to which the proxy delegated the original method.
>>
>> If this method is used with a PersistenceManagerFactory that is  
>> configured with TransactionType RESOURCE_LOCAL, the proxy returned  
>> will dynamically delegate to the PersistenceManager currently  
>> associated with an implementation-defined thread-local variable.  
>> The thread-local variable is inherited by any threads created by  
>> the thread that currently has a PersistenceManager associated with  
>> it. The close method on the proxy clears the thread local variable  
>> to null, and a subsequent invocation on the proxy will create a  
>> new PersistenceManager.
>> </proposal>
>>
>> Craig Russell
>> Architect, Sun Java Enterprise System http://java.sun.com/products/ 
>> jdo
>> 408 276-5638 mailto:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!
>>
>

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!


Mime
View raw message