Patrick,
I agree with your definition. The changes to an object or the objects created should only be visible inside the transaction that changed or created before commit. Other transactions don't see the changes or the new object utile they are commited.
From my experience that's the way databases are handling this situation and also users of castor would expect.
Sylvie could you please open a bug report for this?
See also my comment inline.
Patrick van Kann schrieb:
A transaction would not span multiple threads but between the creation and the access to the JDO in one thread and transaction could be a lot of code. For example the JDO is created by one object and accessed by another object that do not know from each other. In some cases it would cause a lot of problems to pass the object created to all places it needs to be accessed.This is certainly an interesting thread. Can we just clarify what we think the correct behaviour should be from Castor?
In my opinion, Castor should not return created objects via OQL or any
other means until they are committed. That's because in Castor's world,
objects do not exist until they are committed to the database.
I really do believe that otherwise this could cause isolation problems - it's like withdrawing money from your bank account with an uncleared check! It might be OK to allow OQL to return the object within the transaction that created it (from within the transactional cache say), but not within other transactions. But within a single transaction, you should have access to the created object as it should be available as a variable within the scope of the method the transaction is running within - there should be no need to get it from Castor. Transactions don't span multiple threads so there are plenty of ways you can get access to the created object.
As creation of objectX is not commited by T1, for T2 it looks like no objectX is available at load. That's what transaction isolation is for.
Imagine this scenario: Transaction 1 -Start transaction -Create "objectX" -Rollback transaction
Transaction 2 -Start transaction -Load "objectX" via any OQL query -Change "objectX" -Commit transaction
What if the sequence was this (in a multithreaded scenario):
T1 start T1 create "objectX" T2 start T2 load "objectX" via any OQL query T2 change "objectX" T2 commit T1 rollback
This will surely leave your system in an inconsistent state. T2 is a dirty read.
Am I missing something here? I welcome your views.
Cheers,
Patrick
-----Original Message-----
From: Werner Guttmann [mailto:[EMAIL PROTECTED] Sent: 10 November 2004 22:15
To: [EMAIL PROTECTED]
Subject: Re: [castor-dev] [jdo] Reading, in the same transaction, a data
just created (reading via oql query)
Bruce et alias,
after some investigation on my side, I come to believe that whether the
cache is used or not does not make a difference in this case. Why ? If
somebody calls Database.create() as part of as transaction, a cache entry will
not be added until execution of the commit phase. In my tests, I tried
to turn the performance caches on and off, and it simply didn't make a difference.
As already mentioned in a separate reply, I came to believe that this
might have been fixed with the 0.9.6 release candidate, but I cannot pin
down the bug number right now. All tests I have been running complete
successfully, irrespective of whether the id is part of the OQL query or
not.
Werner
On Wed, 10 Nov 2004 14:19:05 -0700, Bruce Snyder wrote:
SYLVIE PALLUEL wrote:
I don't know if this can help you, but I made another test with an
OQL
pass-thru, and I get the new object before the commit phase.
It seems to me that using pass through SQL should only work if you are using autocommit. Are you using autocommit? What database are you
using?
Is there something special to do to enable the OQL query to see the
objects
created inside the current transaction?
There's nothing special that needs to be done. Just as Patrick stated, OQL queries do not look at the cache before going to persistence. This is different from the db.load() method which actually does look at the cache first.
Bruce
--
perl -e 'print unpack("u30","<0G)[EMAIL PROTECTED]&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'
The Castor Project http://www.castor.org/
Apache Geronimo http://geronimo.apache.org/
----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
------------------------------------------------------------------------
----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
--
Syscon Ingenieurbüro für Meß- und Datentechnik GmbH Ralf Joachim Raiffeisenstraße 11 D-72127 Kusterdingen Germany
Tel. +49 7071 3690 52 Mobil: +49 173 9630135 Fax +49 7071 3690 98
Email: [EMAIL PROTECTED] Web: www.syscon-world.de
----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
