On 1 Aug 2007, at 23:00, Vincent Marquez wrote:
> >I'd have thought batching would hold locks as well.
> >Unless you see batching as just queueing calls and applying them when
> >batchComplete() (or whatever we call it) is invoked. But then how do
> >you deal with failures? Is the batch atomic?
> Well, I was assuming they wouldn't hold locks (at least until the
> commit occured). I figured
> a batch might be long running with adds, and with the current
> locking scheme, other reads would block
> until the commit for the nodes that were added/updated, no?
Yes, that's correct, unless you use optimistic locking.
> You could have the commit be optimistic with atomic behavior, or
> non atomic and just have exception notifications. Are either of
> these options?
At the moment optimistic locking is atomic, so even if there is a
version mismatch for one operation, the entire transaction (i.e.,
batch) will fail.
Just like with databases, I'm assuming batch operations would only be
write operations and not read operations?
Lead, JBoss Cache
JBoss, a division of Red Hat