[RE: makeTransactional] (second attempt)

Question

Craig et al.,
We either have confusion on my part, lack of clarity in the spec, or a
bug in Kudo. Can you perform some triage?
Thanks,
David
"White, Abe" wrote:
David --
This is an excellent question. I believe that Kodo's behavior is
correct; i.e. that calling makeTransactional() on a persistent
non-transactional instance during an optimistic transaction does not
guarantee that the state of the instance is compared to that of the
data store. However, my evidence for this is a little shaky:
Section 5.8 of the JDO specification covers optimistic transactions.
Check out p. 40 and 41 where the makeTransactional() method is
discussed. Only for persistent dirty instances does the spec say the
state of the instance is verified against the data store during
commit. The spec also mentions that users should call refresh() if
they want to make sure the state of the instance in memory is correct
(though refresh() is an expensive operation).
From the above evidence I believe that p-clean instances are never
compared to the datastore for consistency. But as I noted, this isn't
a whole lot to go on, so I could be wrong. I encourage you to contact
the JDO spec team about the issue... or if you don't we on the Kodo
team will get around to it eventually.
Let us know if you get any clarification!
-- Abe White
-----Original Message-----
From: David Ezzio
To: Tech Trader JDO List
Sent: 8/12/01 4:59 PM
Subject: makeTransactional
Concerning the makeTransactional() method, the spec (V 0.95 p 79)
says,
"These methods are also used to mark a nontransactional persistent
instance as being part of the read-consistency set of the
transaction."
For transactions with optimistic on and nontransactional read on, I
took
this statement to imply that a call to makeTransactional would force a
comparison of the age of the object's concurrency field (its
optimistic
lock) to the value in the datastore at the time of transaction commit.
I believed that this would occur even if there were nothing dirty to
write in the object or, even, in the transaction. If there were an
age
descrepancy with any of the transactional objects, I expected that an
exception would be raised rather than having the transaction commit.
However, I am not seeing the behavior that I expected in Kudo. So my
question is: am I confused or is there a bug?
David

Answer 1

Hi David,
The intent of makeTransactional is to require the implementation to
check the state of persistent nontransactional instances at commit.
If this is done without a refresh, then the state of the instance at the
moment makeTransactional is called is assumed to be the state to be
checked. If a subsequent refresh is called, then the refreshed state is
to be checked at commit.
David Ezzio wrote:
>
Craig et al.,
We either have confusion on my part, lack of clarity in the spec, or a
bug in Kudo. Can you perform some triage?
Thanks,
David
"White, Abe" wrote:
David --
This is an excellent question. I believe that Kodo's behavior is
correct; i.e. that calling makeTransactional() on a persistent
non-transactional instance during an optimistic transaction does not
guarantee that the state of the instance is compared to that of the
data store. However, my evidence for this is a little shaky:
Section 5.8 of the JDO specification covers optimistic transactions.
Check out p. 40 and 41 where the makeTransactional() method is
discussed. Only for persistent dirty instances does the spec say the
state of the instance is verified against the data store during
commit. The spec also mentions that users should call refresh() if
they want to make sure the state of the instance in memory is correct
(though refresh() is an expensive operation).
This paragraph discusses the state transition, but assumes that the
checking behavior as discussed in 12.5.7 takes place:
These methods are also used to mark a nontransactional persistent
instance as being part of the read-consistency set of the transaction.
In this case, the call must be made in the context of an active
transaction, or a JDOUserException is thrown.
And again in 13.5:
Unmodified instances that have been made transactional will be verified
against the current contents of the data store, to ensure that the state
in the data store is the same as the "before image" of the instance in
the transaction. If any instance is found to have changed, a
JDOUserException is thrown which contains an array of JDOUserException,
one for each instance that failed the verification. The optimistic
transaction is failed. The definition of "changed instance" is a JDO
implementation choice, but it is required that a field that has been
changed to different values in different transactions results in one of
the transactions failing.
Details of the state transitions of persistent instances in optimistic
transactions may be found in section 5.8.
If this is not clear enough, kindly suggest the specific parts of the
specification that you think should be updated.
Regards,
Craig
>>
From the above evidence I believe that p-clean instances are never
compared to the datastore for consistency. But as I noted, this isn't
a whole lot to go on, so I could be wrong. I encourage you to contact
the JDO spec team about the issue... or if you don't we on the Kodo
team will get around to it eventually.
Let us know if you get any clarification!
-- Abe White
-----Original Message-----
From: David Ezzio
To: Tech Trader JDO List
Sent: 8/12/01 4:59 PM
Subject: makeTransactional
Concerning the makeTransactional() method, the spec (V 0.95 p 79)
says,
"These methods are also used to mark a nontransactional persistent
instance as being part of the read-consistency set of the
transaction."
For transactions with optimistic on and nontransactional read on, I
took
this statement to imply that a call to makeTransactional would force a
comparison of the age of the object's concurrency field (its
optimistic
lock) to the value in the datastore at the time of transaction commit.
I believed that this would occur even if there were nothing dirty to
write in the object or, even, in the transaction. If there were an
age
descrepancy with any of the transactional objects, I expected that an
exception would be raised rather than having the transaction commit.
However, I am not seeing the behavior that I expected in Kudo. So my
question is: am I confused or is there a bug?
David--
Craig Russell 650 786-7819
Architect mailto:[email protected]
Sun Microsystems, Inc. http://access1.sun.com/jdo