How does JGPL handle concurrent updates?
1) user1 retrieves dataX, then
2) user2 retrieves dataX, then
3) user1 updates dataX, then
4) user2 updates dataX.
How does JGPL prevent the update by user2?
Good question. To date, JGPL has been used exclusively in server side java apps - 1 vm - 1 database. So, within a VM jginder has transaction managment capabilities to handle these cases. I can provide more detail if you would like, but I think your question relates more to a more traditional client server model.
You have a couple of options, all will require code changes.
1) Use optimistic locking. This would be quite trivial to support. Add a db column to your tables that contains some identifier that allows you determine if a table has changed since the last read. When you update a record, do a select for update and validate the column shows that no change has occurred since the last read. This will hurt performance, so be sure you have the need.
2) Use pessimistic locking. The api for the persistence interface provides a lock method. Currently that is implemented to lock an object from in memory updates. Without too much work this could be altered to once again select for update the row represented by the provided object. The impact to the code and the performance would be even greater.
I've always wanted to add these capabilities, but have not yet had the client need. strange I know, but perhaps that relates to the relatively small number of users.
By the way, have you looked at some of the other open source solutions (castro is highly regarded) for this problem? If so, what did you think? If not, why not?
Actually, I asked out of curiousity. And because
a friend asked me.
Mine is a server-side application with
1 VM. Phase 2 may require multiple-VMs, but
the shared data between multiple users is
read-only. When we need to update this data,
we can bring down the service. Read-write
data is limited to single-users, (e.g. user
profiles), hence not subject to concurrency
I have looked at Castro, but was deterred for 3
1) Its scope and function were for XML and
JDO. I had already determined to use JDOM
for any XML I needed to do, and at the time
I evaluated it, I had only heard of JDO wrt
vague rumours of replacing parts of EJBs.
2) Lack of clear documentation. JGPL had a
nice tutorial. Castor did not.
3) I recalled that it was one of Lutris' projects,
and when I made the decision, Lutris had
run into difficulties. Of course, now that I
double-checked, Castor is NOT a Lutris
project. And ObjectWeb has taken over
Lutris' Enhydra projects.
Log in to post a comment.