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

[Manik Surtani]

On 17 May 2010, at 12:37, Philippe Van Dyck wrote:

> 
> On Mon, May 17, 2010 at 11:47 AM, Manik Surtani <manik at jboss.org> wrote:
> 
> 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?
> 
> Done - ISPN-444

Hmm, about this - I suppose it really isn't enough to wrap the tryLock call since a thread could be interrupted doing a multitude of other things in addition to just acquiring locks - e.g., waiting to write state to a cache store, network comms, etc.

So while I have checked in a fix for ISPN-444 [1], I presume what we really need is a finally block around the InvocationContextInterceptor where all invocations come in [2], to clean up any locks acquired within the scope of the current call.

Thoughts?

Cheers
Manik

[1] http://fisheye.jboss.org/changelog/Infinispan/trunk?cs=1794
[2] http://fisheye.jboss.org/browse/Infinispan/trunk/core/src/main/java/org/infinispan/interceptors/InvocationContextInterceptor.java?r=269#l47

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