[infinispan-dev] lock acquisition - "finally release" it

Manik Surtani manik at jboss.org
Mon May 17 05:47:53 EDT 2010


On 16 May 2010, at 18:35, Philippe Van Dyck wrote:

> Hi all,
> 
> in a servlet environment, you sometimes have to claim back a thread for your thread pool.
> Jetty has a nice "denial of service attack" filter and a setting (maxIdleTime) interrupting servlet threads if nothing comes out (nothing is written in the pipe).
> 
> Well it does not play well with infinispan. Everybody knows that when you open a stream, the best way to reclaim scarce resources is to close it in a 'finally' statement. What about applying it to infinispan locking mechanism ? ;-)
> 
> Calls to acquireLock should be guarded by a finally {releaseLock} (at least to catch an interruptedException)

This is a good point, in the event of a failure (for whatever reason) the lock may still be acquired and should be cleaned up.  Care to create a JIRA for this?

> It looks very easy to implement, but since releaseLock does not seems to be called every time in the code, I need help !
> 
> The only places where aquireLock is called are CacheLoaderInterceptor.loadIfNeeded and EntryFactoryImpl.wrapEntryForWriting.
> 
> And BTW, the locks never expire ... so if you interrupt a thread and the lock is not released, you better say bye bye to the cache entry!

Hmm.  While I agree in principle (we could implement a max lock period in the config file), how do you see this working in practice?  Maintain timestamps of all acquired locks, and have a maintenance thread regularly check these for locks that have expired (and then interrupt the locking thread)?

Cheers
Manik
--
Manik Surtani
manik at jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org







More information about the infinispan-dev mailing list