On Sun, 28 Dec 2003 10:25:53 +0100, Andreas Schildbach wrote:
>Bruce Snyder wrote:
>
>> I'm not following your example completely so let me pose a simple scenario
>> for demonstration purposes:
>>
>> 1) Tx1 reads an instance of ObjectA from persistence
>> 2) Tx2 reads an instance of ObjectA from persistence
>> 3) Tx1 changes a value in the ObjectA instance and persists it. This
>> means that tx2 now is out of sync.
>> 4) Tx2 changes a value in the ObjectA instance and attempts to
>> persist it but receives a ConcurrentModificationException. This
>> is correct behavior
>>
>> Castor does not provide a method of synchronizing the object
>> instances. This is left up to the application because there is no easy,
>> universally acceptable method of achieving this type of behavior.
>
>Let's replace step 4 for a moment:
>
>4) Tx2 uses values from ObjectA for displaying in a web page.
>
>This step can occur repeatedly, and can also occur before step 3.
>
>What is the best/easiest way to always get the actual values with step
>4, without loading the instance from the database on each invocation
>(e.g. by using db.load() again)?
There's no easy answer, but if I had to come up with an answer, this is what it'd be.
Just don't. As Bruce has said,
there's no way to be informed about updates that have been made in other
transaction(s). Just keep your copy in a
'safe place' (e.g. store it to the HttpSession as an attribute), and make up your mind
whether you need to persist any
changes later on. Now, if that's the case, that's exactly where Castor will indicate
to you that you cannot easily store
changes to your data as the underlying data has been changed already. If Castor didn't
warn you, you'd simply wipe
out somebody' else's changes by saving your data ... which would violate normal
ACIDity.
In other words, the recipe should read (for each thread):
a) read your data
b) do something with it (even if you are just storing it).
c) try to persist any changes.
d) deal with any (ConcurrentModification)Exception that is a result of Castor/the
database trying to get transaction
synchronisation right.
Now, the difficult part now is d), as you might have to go back to the user with the
'fresh' data from the database,
and ask him to confirm his action again.
I hope this helps.
Werner
>
>Regards,
>
>Andreas
>
>-----------------------------------------------------------
>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
