More JPA-2 locking support is checked in for HHH-4546. As per Steve's
suggestion, we can now customize dialects to control how core locking
(optimistic +pessimistic) is performed against different database servers.
We now have the following additional Hibernate LockModes that are used
for JPA-
On 10/30/2009 02:08 PM, Steve Ebersole wrote:
> As I said on IRC, my belief is that we should expand this set of lock
> modes specifically to include NO_WAIT variants. Its really just a
> question of for which modes it makes sense. The spec says
> "javax.persistence.lock.timeout" is "defined by t
As I said on IRC, my belief is that we should expand this set of lock
modes specifically to include NO_WAIT variants. Its really just a
question of for which modes it makes sense. The spec says
"javax.persistence.lock.timeout" is "defined by this specification for
use in pessimistic locking" so o
How should we handle the _NOWAIT variants for the three Pessimistic
modes? The JPA2 style is to use the "javax.persistence.lock.timeout
(time in milliseconds, with 0 meaning no wait).
Internally, we need Hibernate core to support the three pessimistic lock
modes (read, write, force_increment)
Hey Thamayanthi,
It really depends what interests you. If you don't know the code base
very well, that would be a good place to start. Also don't discount
helping out on IRC or forums or documentation etc. Those are great ways
to help improve hibernate.
In terms of developing code, the best b
But my point is that the spec is misusing the term repeatable read here.
Repeatable read in database terms is strictly about making sure a
transaction sees the the same data "version" every time it reads a given
row. That has nothing *necessarily* to do with blocking concurrent
writers. In fact M
Hello Everyone,
I would like to contribute in hibernate developement. Can any one provide
guidance to start?
Thanks
Thamayanthi
On Tue, Oct 20, 2009 at 10:45 AM, Scott Marlow wrote:
> On 10/16/2009 03:40 PM, Emmanuel Bernard wrote:
> > When I discussed that with Gavin, I believe this idea is
On 20 oct. 09, at 20:22, Steve Ebersole wrote:
> On Tue, 2009-10-20 at 14:12 -0400, Scott Marlow wrote:
>> On 10/20/2009 12:16 PM, Steve Ebersole wrote:
>>> See my reading of P2 though is more than just ensuring a repeatable
>>> read.
>>>
>>> If T1 does lock(entity, LockModeType.PESSIMISTIC_READ)
It seems to be the RR definition to me
http://en.wikipedia.org/wiki/Isolation_(database_systems)#REPEATABLE_READ
"All data records read by a SELECT statement cannot be changed;"
On 20 oct. 09, at 18:16, Steve Ebersole wrote:
> See my reading of P2 though is more than just ensuring a repeatable
>
On Tue, 2009-10-20 at 14:12 -0400, Scott Marlow wrote:
> On 10/20/2009 12:16 PM, Steve Ebersole wrote:
> > See my reading of P2 though is more than just ensuring a repeatable
> > read.
> >
> > If T1 does lock(entity, LockModeType.PESSIMISTIC_READ) we need to make
> > sure T2 cannot update or delete
On 10/20/2009 12:16 PM, Steve Ebersole wrote:
> See my reading of P2 though is more than just ensuring a repeatable
> read.
>
> If T1 does lock(entity, LockModeType.PESSIMISTIC_READ) we need to make
> sure T2 cannot update or delete that row b4 T1 completes. That's
> blocking, not simply repeatabl
See my reading of P2 though is more than just ensuring a repeatable
read.
If T1 does lock(entity, LockModeType.PESSIMISTIC_READ) we need to make
sure T2 cannot update or delete that row b4 T1 completes. That's
blocking, not simply repeatable read.
On Tue, 2009-10-20 at 17:55 +0200, Emmanuel Ber
On 20 oct. 09, at 17:46, Steve Ebersole wrote:
> Just wanted to point out that "checking" the isolation level may not
> be
> accurate. HSQLDB, for example, lets you set any isolation you want
> and
> dutifully reports it back even though it (used to, at least) only
> supports READ UNCOMMITTE
On 20 oct. 09, at 17:16, Scott Marlow wrote:
>
> In our JPA 1 support, LockModeType of READ is implemented with
> LockMode.UPGRADE (pessimistic lock is obtained). With the above
> proposal, this would change in our JPA 2 implementation to use an
> optimistic lock (just read version at load
Just wanted to point out that "checking" the isolation level may not be
accurate. HSQLDB, for example, lets you set any isolation you want and
dutifully reports it back even though it (used to, at least) only
supports READ UNCOMMITTED. But, I personally think we need to just
assume that we are ru
On 10/20/2009 10:12 AM, Emmanuel Bernard wrote:
>
> On 20 oct. 09, at 15:45, Scott Marlow wrote:
>
>> On 10/16/2009 03:40 PM, Emmanuel Bernard wrote:
>>> When I discussed that with Gavin, I believe this idea is that you can
>>> implement the optimistic locking in the following way:
>>> - when locki
On 20 oct. 09, at 15:45, Scott Marlow wrote:
> On 10/16/2009 03:40 PM, Emmanuel Bernard wrote:
>> When I discussed that with Gavin, I believe this idea is that you can
>> implement the optimistic locking in the following way:
>> - when locking an object read the version number (or if already
>> l
On 10/16/2009 03:40 PM, Emmanuel Bernard wrote:
> When I discussed that with Gavin, I believe this idea is that you can
> implement the optimistic locking in the following way:
> - when locking an object read the version number (or if already
> loaded keep this one - not sure about that detail)
18 matches
Mail list logo
