Re: [Hibernate-devel] Re: share objects between different sessions

[Gavin_King/Cirrus%<CI...@ci...>]

>> (1) Does the "state" of the transient instance include it's id? Since
>> hibernate allows the Session to track id's, I'm thinking, on the face
>> of it, the answer is "no".

> Hmm, this raises the question: How do I find the old record in the
> database ? So, the answer is "yes" because ID is usually a property that
is
> stored inside the transient/persisted object.

What I was really getting at here was: Do we use the id held _inside_ the
object, or do we let the application provide it? Should it be:

  persistentObject = Session.update(transientObject);

or:

  persistentObject = Session.update(id, transientObject);

or should we allow both forms?

>> (2) Does the "state" of the transient instance include it's version
number?
>> I'm thinking the answer is to this would be "yes".

> Yes, a version number would really help. But we have to be aware that
having
> a single version number does _not_ guarantee serializability (there are
> phantom reads and non repeatable reads). Ok, it is possible to set the
> transaction isolation in the jdbc driver to serializable but then the
question
> appears why having version numbers at all.

I'm assuming that the most typical use of this functionality would be to
load a persistent object in one transaction (the first session) and then
update it in a second (transaction and session). ie. It would be used with
what we are calling "long transactions with versioning". Obviously if this
is not the case and we are doing everything in one transaction, versioning
is not such an important issue.

I'm not suggesting that we disable the functionality for non-versioned
objects, merely asking wether we use the version number held by the
transient instance, or the version number held by the existing persistent
instance when we update. It seems clear that it should be the version
in the transient instance.

>> (3) Should replacement replace the actual instance, or just copy its
state
>> into the current persistent instance? I'm thinking: always do a copy.

> Sorry, I don't see a difference between replace and copy (may be my
> english :) If you're thinking: the updated record in the database has the
> same id as before I'm with you.

If I call

  Session.update(transientObject);
  Object persistentObject = Session.load( transientObject.getID() );

Does transientObject == persistentObject ?

I'm thinking *no*. Other persistent objects loaded by the session might
already have references to the object with the given id and it would be
a very difficult problem to swap all their references to point to
transientInstance. Even then, the application might have pointers to
persistentObject. Hence, I favor the form:

  persistentObject = Session.update(transientObject);

which returns another instance of the class, with the same id and
persistent
state as transientObject.

> I think it should be possible to persist single objects and a set of
> single objects at once because:
>  * updating single objects is easy to implement

this would be the first thing to implement.

>  * writing a special collection class with special add/update/remove
>   operations is also easy to implement

It would be nice to have something like:

  Iterator persistentObjects = Session.update(iteratorOfTransients);

But this would be equally useful for other Session operations like

  save(), insert(), delete()

So, i'd rather think about this later on as a seperate feature.

> * persisting a collection of single objects is a very common operation
> I don't think that having the possibility to persist large and complex
> object graphs is really necessary for everyday usage but would be a
> "nice thing to have".

agreed.

>> (5) If the transient instance contains references to other transient
>> instances, we at least need to figure out if some of these are actually
>> references to existing persistent instances and resolve those
references.
>> This would only be possible if the transient instances hold their id.
>> So i guess my initial answer to (1) is wrong and we should only allow
>> replacements for classes which have identifier properties.

> Is it possible to have objects without an identifier ? Are there examples
> where this might be useful ? (for non read-only objects)

hmmmmm I can imagine it might be occasionally useful but hibernate can
not presently use objects without primary keys (the id is used internally
by the Session). Objects without identifiers can not be updated nor
take part in associations, so they are not usually useful.

However, what *is* possible is that the objects themselves do not hold
a copy of the identifier. If the persistent class contains no identifier
property, hibernate can still associate ids with instances *inside* the
session. This mechanism breaks down once we start trying to reuse the
instance in a different session (we won't know what it's id).

My apologies to everyone for slowness lately. I've been sick and also
distracted by some other things.