On Nov 12, 2006, at 02:25, Aristedes Maniatis wrote:
Anyhow, although we haven't done this yet, we would be very
interested in collaborating on any work to tie jgroups into
Cayenne. Since we use Jetty already, and there is some integration
between jgroups and Jetty mentioned, perhaps this will be even easier.
I do think that jgroups is that good for client-server communication
as it is based on IP multicast.
http://www.jgroups.org/javagroupsnew/docs/overview.html
* a further step would be to add a piece of metadata to a Cayenne
persistent object in order to record its current lock state.
Changes to this state would need to be propagated between all
clients in an atomic way.
I do not know if it is relevant, but I recently created a distributed
Lock for our system. It stores the lock state in the database and
uses cayenne optimistic locking to make sure another cayenne instance
does not get the lock at the same time. We do not have that many
locks, only a few to make sure some scheduled jobs only run at a
single node at any given time. The most difficult issue to solve is
how to make sure locks are unlocked. Some sort of timeout is probably
the most secure way to do this. I have implemented this as a subset
of java.util.concurrent.locks.Lock.
http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/locks/
Lock.html
This could be extended to support locking for cayenne persistent
objects. You could use a string version of the ObjectId as a primary
key, a int for the lock state and a timestamp. And some additional
fields for things like username and client ip-number.
Lock l = CayenneLocker.getLock(myObject.getObjectId(), timeoutvalue?);
if(l.trylock()){
try {
// do stuff
} finally {
l.unlock();
}
} else {
// handle the fact that you could not get the lock
}
So it is up to the client developer, not cayenne, to make sure that
doing the stuff that need a lock are only done if he has a lock for
the given object.
Ideas:
* CayenneLocker should use a separate DataContext and cache as
little as possible. I set persistence state to HOLLOW before checking
anything.
* getLock() should check for timeout and clear timed out locks
* Use cayenne optimistic locking for the lock state, username and
client ip-number.
* tryLock() return false if the lock is already locked or the lock-
commit throws an OptimisticLockingException
- Tore.
