cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tore Halset <hal...@pvv.ntnu.no>
Subject Re: Docs and some questions
Date Sun, 12 Nov 2006 14:23:52 GMT
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.

Mime
View raw message