[Hibernate] Session.lockAll(Iterator) [continued from forum]

[Daniel M. <da...@sp...>]

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