Re: JDO design patterns

Question

It is required to match the returned value object to the persistent
object on the return trip, since just calling makePersistent() on the
returned value objects will either lead to another distinct object in
the datastore or a duplicate primary key exception.Is there no method in JDO to say, replace the current object in the
datastore with this one?
Regards,
James W.

Answer 1

ALL,
I am reposting this, since the last attempt caused the note below to
be encapsulated as an attachment.
David
James,
The problem is to get "the current object in the datastore".
Persistent objects are uniquely identified by the value of their
ObjectId. But PC objects in a transient state don't have an ObjectId.
To get around this issue, you could store the ObjectId in a
non-persistent field of the persistent object prior to serializing it
(and thus making the object transient, or a value object as I am calling
it). Then when you're ready to match the value object up with its
persistent one and make changes to the persistent object, you grab the
object ID from where you stored it in the value object, fetch the
persistent object and apply the changes. Thus the method that you
request can be constructed as part of the application's framework, but
it doesn't exist in JDO.
The whole business gets a bit tricky because you also lose your
reference to the PersistenceManager when the object becomes transient.
If you're keeping the PM open (required if you want to have a long
running optimistic transaction) and you have many of them (possible)
then you'll want to store a hash key to the PM as well so that you can
come back to the same PM (and transaction and object cache) from which
you can fetch and apply changes. The PM itself is not serializable, so
a key to your own hash table of PM references is what you need.
From an EJB perspective, if you want to have an optimistic
transaction, you can't have a stateless session bean -- because a
reference to at least one open PM has to be stored someplace in the EJB.
To put stateless session beans and optimistic transactions together
would require some changes in JDO. From a application's perspective, I
would like to see a call that allowed the application to verify that the
transient PC object (value object) that it has is no older than the
persistent object: something like boolean isSameAge(Object idTransient,
Object pcTransient, Object pcPersistent). This call would verify that
the concurrency field of the transient object whose ObjectID must be
supplied by the caller is the same age as the concurrency field of the
persistent object (which must also have the same ObjectId value). With
something like this, the application can extend optimistic transactions
by checking the age of the value object itself after it has obtained a
new PM and the persistent object by ObjectId. The problem with this
approach is that it would require that the field holding the concurrency
value be serialized (not marked "transient"), and that would break the
design goal making enhanced classes serialization compatible with
unenhanced classes. A possible way around this is for JDO to define an
optional interface for PC classes which the application could
implement. If found, the JDO code would use it to perform the
additional magic we want here.
Having an optional interface might also help regiment application
handling of the hashcode() and equals() methods as well.
David
[email protected] wrote:
>
It is required to match the returned value object to the persistent
object on the return trip, since just calling makePersistent() on the
returned value objects will either lead to another distinct object in
the datastore or a duplicate primary key exception.Is there no method in JDO to say, replace the current object in the
datastore with this one?
Regards,
James W.