openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Abe White <>
Subject Merge strategies and OPENJPA-245
Date Fri, 04 Apr 2008 17:22:18 GMT
OpenJPA typically uses an enhancer-added "detached state field" to
differentiate newly-constructed instances that need to be inserted vs.
detached instances that need to be updated on merge.  This is covered in
more detail in the user manual.

OpenJPA also allows users with version fields to manually construct a
"detached" instance just by setting the pk fields to the pks of an
existing instance and setting the version field appropriately.  A
non-default version field value is considered a directive to treat an
instance as existing on merge, even if the detached state is missing.

The OPENJPA-245 JIRA issue describes a case in which a user wants to
manually construct a "detached" instance instead of going through the
detach procedure, but the user's entity doesn't have a version field.  A
fix was submitted in January which basically changes our merge algorithm
to always issue a database query to see if an instance with the same pks
exists when no detached state is present.

This has a few side effects:  
1. This fix makes merging much more database-intensive, as we have to
issue queries for all instances without detached state.  Though it might
not matter to OpenJPA devs, JDO actually treats persisting and merging
the same, so the inefficiency is even more pronounced in JDO.
2. With this fix, the results of OpenJPAEntityManager.isDetached (and
the methods it relies on like PersistenceCapable.pcIsDetached and
Broker.isDetached) are no longer considered reliable -- the
VersionAttachStrategy doesn't trust these results, but does its own
lookup in the DB.
3. The fix changes the place that many exceptions will be thrown from
flush/commit to merge.  This is allowed by the spec and is arguably
better (exceptions are thrown earlier), but I just want to point out
that it is a change. 

I think we can fix 245 in a way that lessens the side effects.  A couple

1. There is existing code in PersistenceCapable.pcIsDetached to consider
an instance detached if it has any auto-assigned pk fields that aren't
set to their default values.  Right now this code is only executed if
the user has configured things to never use a detached state field.  We
could easily change things, however, so that a non-default auto-assigned
pk field is treated like a non-default version field: it always signals
a detached instance, even when detached state is enabled but missing.
This fixes 245 (which happened to involve an entity with auto-assigned
pk fields) and removes all 3 side effects above.  

The downside is that if you have an entity without a version field and
without auto-assigned pk fields and you attempt to construct a new
"detached" instance and merge it instead of actually going through the
detach process, OpenJPA will (correctly, but not desirably) think the
instance is new rather than detached.  

This is a pretty esoteric use case.  But even in this case, users have
to option of turning off the detached state field via configuration, and
OpenJPA will fall back on doing a DB query for the pk fields to
determine whether these instances are detached vs. new.  So there is
still a way to handle this case, you just have to set a config property.

2. Another option would be to change VersionAttachStrategy to only do a
DB lookup for types that have no version field.  This would alleviate
the inefficiencies for users that have version fields.  Unfortunately,
it wouldn't change any of the side effects of the existing fix for any
other users.


I would vote for proposal #1 above.  It returns us to very efficient
merge behavior (and JDO persist behavior) while allowing most users
(those with either version fields or auto-assigned pk fields) to still
manually construct and merge "detached" instances.  The only users left
out of the fix are those who want to manually construct and merge
"detached" instances without version fields or auto-assigned pk fields.
Even these users can turn off detached state, though, to force us to do
DB lookups when determining whether an instance is detached vs. new.


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.

View raw message