openjpa-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: detachment, getReference(), and openjpa.DetachState
Date Wed, 17 Jan 2007 19:31:06 GMT
Here's what the spec says about getReference.

/**
  * Get an instance, whose state may be lazily fetched.
  * If the requested instance does not exist in the database,
  * the EntityNotFoundException is thrown when the instance
*state is first accessed.(The persistence provider runtime is
  * permitted to throw the EntityNotFoundException when
  * getReference is called.)
*The application should not expect that the instance state will
  * be available upon detachment, unless it was accessed by the
  * application while the entity manager was open.
  * @param entityClass
  * @param primaryKey
  * @return the found entity instance
  * @throws IllegalArgumentException if the first argument does
  * not denote an entity type or the second
  * argument is not a valid type for that
  * entity’s primary key
  * @throws EntityNotFoundException if the entity state
  * cannot be accessed
  */
public <T> T getReference(Class<T> entityClass, Object prima-
ryKey);

If I read it correctly, doing the following will result in a detached  
instance with no state (assuming that the getReference is the first  
time this persistence context has seen the instance):

TestClass tc = em.getReference(TestClass, testoid);
em.close();

So without actually seeing the failing CTS test, the test itself  
might be at issue.

That said, a couple of comments below...

On Jan 17, 2007, at 10:52 AM, Patrick Linskey wrote:

> Hi,
>
> In working on the CTS, we've discovered some assumptions that cause
> OpenJPA to fail. The CTS obtains records via calls to getReference(),
> and then does some work with the objects.
>
> The tests fail outright with default OpenJPA settings, as the
> openjpa.DetachState property defaults to 'loaded'. Instances obtained
> via getReference() have not yet been loaded, so there is no data
> available when the instances are detached.
>
> The tests can be made to pass by setting the openjpa.DetachState
> property to 'fgs', which causes OpenJPA to explicitly load all the
> fields in the default fetch group at detachment time. (Incidentally,
> this raised the issue being tracked with OPENJPA-103.)
>
> However, I'm not totally happy with the options available for the
> openjpa.DetachState setting. Currently, DetachState can take one of  
> the
> three values:
>
> loaded: detached objects contain exactly the fields that have been
> loaded during the persistence context's life
>
> fgs: detached objects contain exactly the fields in the current fetch
> configuration at detach time

The fetch configuration in JDO includes two distinct flags:  
DETACH_LOAD_FIELDS and DETACH_UNLOAD_FIELDS. If the  
DETACH_UNLOAD_FIELDS is set to false, it behaves like your proposal  
for loaded-and-fetched-groups.

Would it be possible to implement the LOAD and UNLOAD behavior in  
openJPA?

Craig

P.S. The Reference Implementation for JSR-220 has a non-spec feature:  
the ability to load non-loaded fields of detached instances. This  
behavior might have influenced the CTS test inappropriately.
>
> all: detached objects are fully traversed at detach time
>
>
> I think that it'd be valuable to have a fourth option:
> loaded-and-fetch-groups. Using this setting, detached objects would  
> have
> all the fields in the current fetch configuration, plus all the fields
> that the business code happened to access during the transaction. This
> is different than 'fgs' because 'fgs' will actually clear fields that
> are not in the current fetch configuration. It is different than
> 'loaded' because it will ensure that instances obtained via
> getReference() are hydrated prior to detachment.
>
> Thoughts?
>
> -Patrick
>
> -- 
> Patrick Linskey
> BEA Systems, Inc.
>
> ______________________________________________________________________ 
> _
> Notice:  This email message, together with any attachments, may  
> contain
> information  of  BEA Systems,  Inc.,  its subsidiaries  and   
> affiliated
> entities,  that may be confidential,  proprietary,  copyrighted   
> and/or
> legally privileged, and is intended solely for the use of the  
> individual
> or entity named in this message. If you are not the intended  
> recipient,
> and have received this message in error, please immediately return  
> this
> by email and then delete it.

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