[
https://issues.apache.org/jira/browse/OPENJPA-1545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12849257#action_12849257
]
Pinaki Poddar commented on OPENJPA-1545:
----------------------------------------
The recommendation to add a version field is OK
-- but what happens with this lite detachment when an entity does not use a
version field?
Can I merge() the object graph back when this detach lite was used with some
entities without a version field?
If yes, why did the test persistent entities that worked before this change
without version field required addition of a version field?
If no, how does that discrepancy manifest in the user application code -- does
this new mechanics detect and raise an exception when it meets an unversioned
entity --
or does such usage violate data integrity silently? Do we have a test that
shows such behavior?
> Add new Detach processing
> -------------------------
>
> Key: OPENJPA-1545
> URL: https://issues.apache.org/jira/browse/OPENJPA-1545
> Project: OpenJPA
> Issue Type: Improvement
> Components: performance
> Affects Versions: 2.0.0-beta2
> Reporter: Rick Curtis
> Assignee: Rick Curtis
> Fix For: 2.0.0
>
> Attachments: OPENJPA-1545.patch
>
>
> There have been a number of mailing list posts where the net of the post is
> that someone doesn't want OpenJPA to detach their Entities because after the
> commit happens, then are all going to be gc'd. All of the detach processing
> ends up being a waste. I also observed this same behavior when running some
> performance tests.
> With this JIRA I'm going to add a new openjpa.DetachState configuration
> option which will enable a new, super fast, minimalistic detach approach.
> This change is targeted at detach processing that happens due to an
> AutoDetach. Explicit detaches(ie: em.detach(..) ) will work as they always
> have before.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
