NHibernate: exclusive locking

[whoami]

Ik heb een NHibernate ICriteria waarbij ik een bepaalde instance van een entity wil ophalen.

Nu wil ik voorkomen dat andere threads / users die entity ook kunnen lezen, als die momenteel door een andere thread opgehaald is; maw, ik wil het record in de database, dat die bepaalde entity voorstelt, exclusief gaan locken.

Momenteel ziet mijn ICriteria er als volgt uit:

C#:

With.Transaction (session, IsolationLevel.Serializable, delegate
{
     ICriteria crit = session.CreateCriteria (typeof (TarificationProfile));

      crit.SetLockMode (LockMode.Upgrade);

       crit.Add (Expression.Eq ("Id", tarificationProfileId));

       TarificationProfile profile = crit.UniqueResult<TarificationProfile> ();

        nextNumber = profile.AttestCounter;

        profile.AttestCounter++;

        session.SaveOrUpdate (profile);
});

Zoals je kan zien, issue ik een 'UpgradeLock', wat resulteert in een SQL query die de updlock & rowlock locking hints gebruikt.
Dit voorkomt echter niet dat een andere user / connectie dat zelfde record kan lezen (het kan wel niet ge-updated worden tot wanneer het record weer vrijgegeven is).
Echter, ik wil dit nog een stapje verder; ik wil dat er een xlock locking hint gebruikt wordt, dus:

code:

SELECT ... FROM tabel with (xlock)

ipv

code:

SELECT ... FROM tabel with (updlock, rowlock)

Maar, het lukt me niet om NHIbernate dit aan het verstand te krijgen.... Misschien zie ik iets over het hoofd ?
Ik kan natuurlijk ook de SQL query zelf gaan schrijven, en NHibernate die SQL query laten uitvoeren, maar dat vermijd ik liever.

[RobIII]

Ik roep maar even wat, maar heeft het niet hier mee te maken?

[whoami]

Nee; ik slaag er niet in om NHibernate een query te laten genereren , die een xlock gebruikt.
thx anyway.

[ Voor 7% gewijzigd door whoami op 22-04-2009 10:40 ]

[RobIII]

whoami schreef op woensdag 22 april 2009 @ 10:40:
Nee; ik slaag er niet in om NHibernate een query te laten genereren , die een xlock gebruikt.
thx anyway.

Oh; dan begreep ik "het lukt me niet om NHIbernate dit aan het verstand te krijgen" anders Anyhow. Had je maar duidelijker moeten zijn... n00b

[bigbeng]

Volgens mij slecht nieuws:
http://74.125.77.132/sear...&cd=3&hl=nl&ct=clnk&gl=nl
(even de cache gepakt van google, want hibernate plat)

Zo te zien zit de combinatie die je nu krijgt (rowlock, updlock) er ook pas "net" in.

[dotcode]

De postings gaan over versie 1 en 1.2, voor 2.0 zou je moeten uitzoeken of het nog steeds zo is. Maar ik vrees dat je zelf je query zal moeten maken. Ipv het door NHibernate te laten doen, wat natuurlijk tegen alles is.

Je kan ook nog kijken of je reads kan doen binnen je transactie (serializable transactions). Dan kan je ook niet lezen als iemand anders aan het lezen is. Maar je performance zal er niet beter op worden.

9. Transactions
As we have seen, the standard pattern for executing a use case is to get a Session from the SessionFactory, get a Transaction from the Session, interact with the database via the Session, commit the Transaction and close the Session. Details of the exception handling have been given above. This is fine for normal, fully serialised database transactions but there are two situations when it is not fine:

When using an isolation level other than full serializable. There are 4 standard transaction isolation levels: Read Uncommitted, Read Committed, Repeatable Read and Serializable. They indicate different levels of locking strategies used within transactions and effect just how isolated one transaction really is from other transactions running simultaneously. Thus Serializable means that two transactions run as if one had completely finished (committed or rolled back) before the other had started. In practice, providing this level of isolation requires considerable resources and causes problems with scalability of applications. For this reason, most applications use a weaker form of isolation and use other strategies to overcome the consequent problems that can arise.

.....

[Alarmnummer]

Ik had hetzelfde probleem bij een klant voor hibernate en we hebben daar uiteindelijk een native sql query in gezet en via hibernate magic laten mappen op objecten.

Ik neem aan dat nhibernate ook support heeft voor native queries..anders kan je natuurlijk altijd een whoami-dialect maken

[whoami]

Alarmnummer schreef op vrijdag 24 april 2009 @ 18:30:
Ik had hetzelfde probleem bij een klant voor hibernate en we hebben daar uiteindelijk een native sql query in gezet en via hibernate magic laten mappen op objecten.

Ik herinner me een MSN sessie die we ooit eens hadden hierover, maar ik kon me de test-code die ik toen had gemaakt, niet meer terugvinden.

Ik neem aan dat nhibernate ook support heeft voor native queries..anders kan je natuurlijk altijd een whoami-dialect maken

NHibernate heeft idd ook die support voor native queries, en doet wat magic om uiteindelijk entities terug te geven, en dat heb ik dan ondertussen ook een beetje gedaan ....
Wel een beetje jammer ondertussen, want dit is ondertussen query nr 3 die ik in native SQL mag gaan doen voor dit project(je) ...

(Query 1 was overkill om via HQL of ICriteria te doen, en Query 2 had ik eerst dmv de Criteria API geschreven, nadien omgezet in HQL om de coalesce functie te kunnen gebruiken, en uiteindelijk in native SQL geschreven omdat NHibernate nog altijd geen 'conditional joins' ondersteunt (with keyword in hibernate)).

[EfBe]

Het probleem met dit soort 'oplossingen' is dat het hoe dan ook tegen je gaat werken. Een row locken voor een bepaalde user/thread zodat geen andere thread het kan lezen is geen oplossing, voor wat voor probleem dan ook, het punt is nl. dat die lock alles tegenhoudt, en je applicatie in feite in deadlock kan raken, bv wanneer de lock niet wordt opgeruimd om wat voor reden dan ook (of niet tijdig). Dit soort problemen moet je altijd oplossen op een andere manier, nl. via functionality locking: dus de functionaliteit die die rows gaat benaderen is locked of niet voor code, niet de data zelf.