Hello Craig,
I see the point when operating in attached mode. Does it make sense to
have immediate memory consistency when working with detached objects?
Theoretically, all the information seems to be there to do it, but I'm
not sure what implications this would have on the implementation (i.e.
enhanced code and StateManager behaviour).
Regards,
Jörg
Craig L Russell wrote:
Hi Jörg,
On Jun 10, 2008, at 5:30 AM, Joerg von Frantzius wrote:
Craig L Russell schrieb:
Hi Jörg,
On Jun 9, 2008, at 1:43 AM, Joerg von Frantzius wrote:
Hello Craig,
what I really meant was: when modifying state of bidirectional
associations on detached objects, should those detached objects
immediately reflect consistent bidirectional state in the VM even
before attaching? E.g. set a one-to-one association from one side,
and immediately see the newly associated object from the other side.
Well, no. Detached objects are not associated with a
PersistenceManager and so flush() or commit() cannot by definition
be applied to them. So there is no specified behavior that applies
to relationships of detached objects.
"15.3 Relationship Mapping" says that "Regardless of which side
changes the relationship,
flush (whether done as part of commit or explicitly by the user)
will modify the datastore to
reflect the change and will update the memory model for consistency."
There is no flush when modifying detached objects, so this doesn't
really sound like the memory model should get updated before the
detached objects are attached again and a flush actually happens.
From an application programmer's point of view, it would of course
be desirable if behaviour was consistent both in attached and
detached state.
It is consistent. If you flush or commit, all the specified behavior
occurs, regardless of where the changes were made (attached or
detached).
That leads me to the question: why is the memory model to be updated
only after flush()?
When I set an association and read it afterwards from the same side
that I modified, I'll immediately see my changes without having to
call flush() inbetween. So the behaviour for "seeing results of
association modification" is depending on which side of the
association I'm looking at. I wonder if that is really necessary?
IMHO, it would be more consistent if an application programmer didn't
have to think about which side of a bidirectional association (s)he
is looking at.
Yes, you can make a case for the jdo implementation immediately
updating the other side of a managed relationship. However, it's not
clear to me that the jdo implementation is the right place to do this.
The rationale for the currently specified behavior is this:
There is only one datastore artifact (the foreign key) that represents
both sides of the relationship. So at flush (when the jdo
implementation synchronizes the state of memory and datastore) both
sides of the memory relationship must be consistent with the datastore
artifact.
Between beginning a transaction and flushing the changed state to the
datastore, there is no other defined consistency point. From an
application perspective, there is no point at which the application is
done making changes that are supposed to be consistent. That is,
consistency of the memory model may change during processing.
If you're looking for consistency in memory, the application is free
to implement whatever behavior is appropriate to ensure consistency,
including modeling the relationship as a separate object and using
methods to manage the relationship instances.
But even then, there is time between setting one side of the
relationship and setting the other side to be consistent. So the
memory model always has a delay during which time the memory model is
inconsistent. So it's a matter of defining the consistency point where
both sides are supposed to be consistent with each other. In the case
of jdo, there is a natural consistency point that we've used for other
cases, such as construction of a new instance. We don't assume the
newly constructed instance is self-consistent until flush.
Regards,
Craig
Once the detached object is brought into the domain of a
PersistenceManager via makePersistent, the flush and commit behavior
applies.
Regards,
Craig
Regards,
Jörg
Craig L Russell schrieb:
Hi Jörg,
On Jun 6, 2008, at 10:30 AM, Joerg von Frantzius wrote:
Sorry for not having had any time to look into this more
thoroughly yet. I'll hopefully find it next week.
I think I experienced problems with changing bidirectional
relationships on detached objects. Now I'm not sure whether the
spec intended those to be managed as well?
Sure, any change to a persistent field of a detached object should
be reflected in the database upon reconnection and commit.
If you can write a test case, we'd be happy to consider adding it
to the TCK.
Craig
Craig L Russell schrieb:
HI Jörg,
On May 27, 2008, at 9:51 AM, Joerg von Frantzius wrote:
Hi,
when looking at the relationship tests in
org.apache.jdo.tck.mapping, it seems that the tests for
bidirectional integrity only test changing relationships from
the "mapped-by" side of the relationship? That's my impression
at least from looking at the method names e.g. in
Relationship1ToManyAllRelationships.java.
There are a few relationship tests, and the intent was (is) to
test changing relationships from both sides.
If you can't find what you're looking for (in all the tests)
please let us know.
Craig
I'm asking this because I believe to see inconsistencies with
bidirectional relationships in the RI.
Regards,
Jörg
--
____________________________________________________________________
artnology GmbH - Milastraße 4 - 10437 Berlin - Germany
Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO)
Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376
UST-Id. DE 217652550
Craig Russell
Architect, Sun Java Enterprise System
http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
--
____________________________________________________________________
artnology GmbH - Milastraße 4 - 10437 Berlin - Germany
Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO)
Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376
UST-Id. DE 217652550
Craig Russell
Architect, Sun Java Enterprise System
http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
--
____________________________________________________________________
artnology GmbH - Milastraße 4 - 10437 Berlin - Germany
Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO)
Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376
UST-Id. DE 217652550
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
--
____________________________________________________________________
artnology GmbH - Milastraße 4 - 10437 Berlin - Germany
Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO)
Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376 UST-Id.
DE 217652550
Craig L Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
--
____________________________________________________________________
artnology GmbH - Milastraße 4 - 10437 Berlin - Germany
Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO)
Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376
UST-Id. DE 217652550
