What seems to be missing is an overload with a custom timeout, it may
be useful to try locking with a shorter timeout in the first attempt
(maybe even 0?) like we do for deadlock detection.
But that is a bit orthogonal, as it would be useful for write
operations as well, so maybe a 6.0 idea...
On Thu, Apr 26, 2012 at 2:55 PM, Mircea Markus <mircea.markus(a)jboss.com> wrote:
On 26 Apr 2012, at 14:42, Erik Salter wrote:
> FWIW, I implement a TryLock like this:
>
> boolean success = cache.getAdvancedCache()
> .withFlags(Flag.FAIL_SILENTLY).lock(key);
+1, this seems like solving the issue.
>
> Regards,
>
> Erik
>
> -----Original Message-----
> From: infinispan-dev-bounces(a)lists.jboss.org
> [mailto:infinispan-dev-bounces@lists.jboss.org] On Behalf Of Galder
> Zamarreño
> Sent: Thursday, April 26, 2012 6:59 AM
> To: Mircea Markus
> Cc: infinispan -Dev List
> Subject: [infinispan-dev] Time for a tryLock() ?
>
> Looks like rolling back the transaction when a lock timeout is encountered
> can be problematic:
https://community.jboss.org/message/731307#731307
>
> Maybe time to implement a tryLock() that attempts to acquire the lock but
> does not rollback the transaction if it cannot acquire it?
>
> Thoughts?
> --
> Galder Zamarreño
> Sr. Software Engineer
> Infinispan, JBoss Cache
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev