The summary of the situation is that I think (thought) that
Session.lockAll(Iterator) would be a useful addition to hibernate. It would
mean one trip to the db for the whole set of objects locked rather than 1 per
object, and all objects would be locked atomically, (maybe) reducing
deadlocks.
The forum thread is at:
https://sourceforge.net/forum/forum.php?thread_id=729431&forum_id=128638
> > Personally I'd rather introduce a lockAll(Iterator) method,
>
> Yes, you are perfectly correct, of course. I'm just feeling a bit quesy
> about adding a method to the session that takes an iterator when every
> other method takes a single object or a query.....
>
Agreed, it is a bit of an eyesore.
>
> Alright, I'll 'fess up. I don't really think people should be needing to
> think about locking for themselves. I added the existing functionality
> because users requested it and I sort of needed an answer to "can Hibernate
> do pessimistic locking?". However, its not an approach I would personally
> use in very many situations. I'm a little worried that if we clutter the
> Session interface with too many methods dealing with concurrency, then
> people will think they need to manage concurrency themselves whereas in
> most cases they dont.
>
Agreed. It's great not having to do anything special 90% of the time.
What chance of factoring out a ConcurrencyManager retrievable from Session for
all the 'black-art' methods? At least this way there is only one point to
document with 'advanced use only'.
I think there are probably more methods which could be added to this
interface, checking object versions without locking, adding objects which
need version checks at commit time, maybe others.
However I'm mindful of the fact that these wouldn't be useful for most
situations and could be classified as bloat.
Also, if you want to remain database neutral, some of these things, including
locking, are worth diddly-squat as you have to cater to the lowest common
denominator.
>
> But if you want to implement a lock(Iterator), I'm happy to include that
Given that I've decided to try and remain db neutral I'll implement the l.c.d.
solution first. I'll have a go at it after that.
Maybe the locking won't even be that much help.
And maybe I'll find some other things that would fit itno a ConcurrencyManager
interface.
> (its only *one* extra method, after all).
>
Famous last words? :)
>I don't think we need to call it
> lockAll(), given Java's rules for resolving overloaded methods.
>
This would be determined by static type info though.
I can't imagine anyone writing
Object o = set.iterator();
but there might be more imaginative people out there.
Peace of mind for three letters.
Cheers
Dan
>
> :)
>
> Gavin
|
