This one time, at band camp, Andreas Schildbach said:
Please see my answers inline:
AS>I'm currently evaluating using Castor in a Web Application.
AS>
AS>The applications uses Data Objects which are held in the HTTPSession.
AS>The main problem I am trying to solve is that when two users are working
AS>on the same Data Object (e.g. id=2), currently (in my own simple Data
AS>Object implementation) the Users do not see the changes of the other
AS>User, because the each user has its own copy of that Data Object in the
AS>HTTPSession.
AS>
AS>Can Castor/JDO solve this problem?
AS>
AS>I'm thinking of using the following fragment for loading the Data Object
AS>into the Session (only happens once for a new Session):
AS>
AS> db.begin();
AS> session.setAttribute("data", db.load(Data.class, new Integer(id));
AS> db.commit();
AS>
AS>This fragment is for displaying a view of the Data Object:
AS>
AS> db.begin();
AS> Data data = (Data) session.getAttribute("data");
AS> ...use getters on data to read values...
AS> db.commit();
AS>
AS>And this fragment is for someone updating the Data Object:
AS>
AS> db.begin();
AS> Data data = (Data) session.getAttribute("data");
AS> ...use setters on data to update values...
AS> db.update(data);
AS> db.commit();
AS>
AS>It is my understanding that db.load returns different instances even for
AS>the same Identities (e.g. id=2), so that the transactions can be
AS>isolated against other transactions that can potentially contain
AS>operations on the same identity. Is this true?
Yes, this is exactly true.
AS>If someone changes values of one of the instances, the change initially
AS>only affects the one transaction.
Correct. Each tx has its own context and does not affect the context of
other txs.
AS>But then, in the next transaction, the values of the two "identical"
AS>Data Objects should be synchronized again, so every view on the data
AS>displays the same (updated) values. Is this correct?
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. Castor
performs dirty checking of objects before persisting changes which is
what causes the ConcurrentModificationException to be thrown. I've seen
people catch this exception and handle it within there application but
this is really a hack. There are too many situations where you would
want to know that a ConcurrentModificationException was thrown to just
handle it automatically.
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://incubator.apache.org/projects/geronimo.html
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
