Hibernate version: 1.2

hi,
i want to update an entity using current stored values in db.
for example, when an item was read, it is needed to update its "visitCount" property.
if i use ado.net, i will execute "update table1 set visitCount=visitCount+1 where id=11"

this is needed for times an application experiences high traffic.
it is possible to load an entity for more than 5 requests at same time (for example in just 100 miliseconds or less)

i can not use nhibernate update because it updates record using loaded value.
for example, it will load entity when its "visitCount" is 10 and updates it, set its visitCount to 11, but between load and update, it may visited 4 other times. in this situations, visitCount must be 15 not 11.

can any one help me?

thanks in advance

Hi,

I can think of a few ways of handling this (there will probably be more, but this is just what comes to mind):


1 - Upgrade the locking:

You can upgrade the lock on the object when you read it. Bear in mind this will probably serialise access to a given row in the database, and might cause contention. The best way is to try it and stress test it.



2 - Use a regular ADO.Net command object:

You can use a regular ADO.Net command object on the same session/transaction objects you already have:



3 - Upgrade to NH2.0

The current trunk code has the ability to do DML-style statements in HQL. Note, NH2.0 isn't in Alpha yet (although it's very close, and it may only be a couple of months till the first GA release - no guarantees though).

http://www.hibernate.org/hib_docs/reference/en/html/batch.html#batch-direct


I hope one of these helps.

Regards,
Richard

Thanks FlukeFan

1. when i get an entity for upgrade, does other requests must wait for upgrade to complete this upgrade? if so this will reduce the speed and may cause to process deadlock (in db or application). did you used this method?

2. i thought your second method is good (works until NH2.0).

Hi,

On option 1, yes other requests will have to wait until an existing request has finished (depending on DB vendor) ... the only way to test if this is acceptable is to try it. If all requests obtain locks in the same order, I don't think you'll get a deadlock. I have used similar techniques in the past to serialise access to certain objects.

I suspect that option 2 will still create a lock (I don't think you can avoid this if you are using transactions). It is straightforward to upgrade to HQL once NH2.0 is available.

Regards,
Richard