Ralf, Patrick et alias,
nothing to add, to be honest. Let's open a bug and close it immediately, as I
simply cannot reproduce Sylvie's problems ... I will attach the tests I use as
soon as the bug has been created, so that somebody else can run then against
0.9.5.3, and see whether this makes a difference. Though This most
likely is not going to be me, as I am moving flats this weekend.
Werner
On Thu, 11 Nov 2004 11:54:13 +0100, Ralf Joachim wrote:
>
>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:
>> 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.
>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.
>>
>> 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
>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.
>>
>> 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
>
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
