db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Beams (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JDO-522) Draft proposal for CopyOnAttach property
Date Fri, 14 Sep 2007 06:00:36 GMT

    [ https://issues.apache.org/jira/browse/JDO-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12527362

Chris Beams commented on JDO-522:

Also from the recently sent email, an example that illustrates the utility of this new property:

PersistenceManagerFactory pmf = JDOHelper.getPersistenceManagerFactory("jdo.properties");

assert pmf.getDetachAllOnCommit() == true;
assert pmf.getCopyOnAttach() == false;

// assuming (for convenience) that there's a single instance of an Employee in the database,
let's query for it, detaching on commit.
final Employee emp;
    PersistenceManager pm = pmf.getPersistenceManager();
    emp = (Employee) pm.newQuery("select unique from Employee").execute();

// 'emp' is now detached-clean
assert isDetached(emp) && isClean(emp);


// 'emp' is now detached-dirty
assert isDetached(emp) && isDirty(emp);

Employee returned;
    PersistenceManager pm = pmf.getPersistenceManager();
    returned = pm.makePersistent(emp);

// 'emp' is now detached-clean.
assert isDetached(emp) && isClean(emp);

// and no copy was made during attachment
assert emp == returned;

Normally, without CopyOnAttach == false (i.e.: current-world behavior), the final state of
'emp' in the example above would be 'detached-dirty' and 'returned' would be a brand new instance
ending up 'detached-clean'.

The new CopyOnAttach == false functionality allows the user to detach, modify and attach the
same object an indefinite number of times without incurring a) the performance cost of copying
and b) the usability cost of having to assign 'emp' to the return value on each call to makePersistent().

In the current world, the user *could* detach, modify and attach the same 'emp' object an
indefinite number of times, simply disregarding the returned value, but there are two ill
effects of doing this: a) copies are needlessly made, and worse, b) the parameter 'emp' instance
remains forever 'detached-dirty'.  This means that any field ever dirtied in 'emp' will always
be flushed to the datastore, even if it is not further modified during subsequent iterations.
 This would be confusing to the user and another potential source of performance problems.
 Allowing the 'emp' instance to transition back to persistent-dirty and subsequently to detached-clean
after commit solves this problem completely.

> Draft proposal for CopyOnAttach property
> ----------------------------------------
>                 Key: JDO-522
>                 URL: https://issues.apache.org/jira/browse/JDO-522
>             Project: JDO
>          Issue Type: Task
>          Components: api2
>    Affects Versions: JDO 2 maintenance release 1
>         Environment: n/a
>            Reporter: Chris Beams
>            Assignee: Chris Beams
>             Fix For: JDO 2 maintenance release 1
>         Attachments: proposal-CopyOnAttach.rtf
> Minutes: JDO TCK Conference Call Friday, Aug 10, 9 am PDT
> On 8/10/07, Craig L Russell <Craig.Russell@sun.com> wrote:
>     Attendees: Chris Beams, Matthew Adams, Michelle Caisse, Craig Russell
>     Agenda:
>     3. Attach (makePersistent) a detached instance always merges changes
>     into the cache. Can this behavior be changed to make the parameter
>     instance change its state, throwing an exception if there already is
>     an instance in the cache, based on a user-specified property? Seems
>     like this would be a good addition to the spec. AI Chris prepare a
>     proposal for the jdo expert group alias.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message