On Tue, Jul 5, 2011 at 1:45 PM, Sanne Grinovero <sanne(a)infinispan.org> wrote:
That's an interesting case, but I wasn't thinking about that.
So it
might become useful later on.
The refcount scenario I'd like to improve first is about garbage
collection of old unused index segments,
we're counting references from open searchers and allow to finish to
run queries on still open segments
while they are being deleted: at the same time, these delete
operations are run in batch operations in background threads,
I couldn't possibly run them in a transaction as it would likely not
have enough memory to complete it, and anyway they're run async
to the rest of the application. So timing is not very critical, but
having a wrong increment/decrement on the counter can cause
many issues and so this must rely on atomic operations. Current
implementation acquires a pessimistic lock on the integer,
having a distributed "AtomicInteger" as discusses on the train would
be a simple improvement.
I think I got it now, your references are from application objects to
cache keys, so you don't have anything else that you need to modify in
the same transaction.
You only have reads, unless the refcount reaches 0, in which case you
also do a remove.
It's clear to me now that the distributed AtomicInteger approach would
be best in your case, so that means I haven't found a real-life
problem that requires in-transaction atomic operations yet ;-)
Dan
Sanne
>
> Dan
>
> _______________________________________________
> 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