<<Thank you for your post Katz. I understand what you are saying but
wouldn't that imply that you aggregates know about locking mechanisms?>>

Assuming you mean relying on nh to handle the "aggregate level" optimistic 
lock... No, this doesn't involving the domain except that you need to find the 
root from underlying entities.

As you probably know nh supports opt lock out-of-the-box. Assuming everything 
in your aggregates is bidirectional (eg ISomeInterface.Parent/Root), you can 
find the root from dirty entities and make the root dirty as well. That will 
give you optimistic lock on the db row for the root and implicitly; on the 
aggregate (because every object in the aggregate changes the same version 
column).

You can use IInterceptor for this (that we use; this app is getting old...) or, 
I guess, similar affects can be done using more modern "events and listeners". 
If these things are new to you, Google can give you a good start.

I don't say this is a perfect solution in any scenario, but if you can pay the 
price to do this at persist time and feel comfortable having birefs, I think it 
works quite fine.

________________________________________
Från: [email protected] [[email protected]] f&#246;r Nuno Lopes 
[[email protected]]
Skickat: den 17 februari 2009 17:21
Till: nhusers
Ämne: [nhusers] Re: Objects State Validation && Business Rules in non Trivial 
Domain  Models

@Roger Katz,

Thank you for your post Katz. I understand what you are saying but
wouldn't that imply that you aggregates know about locking mechanisms?
I'm not stating that I think it is bad, but can you give me an example
of how to for the vesion of an object to be checked and update another
is the same transaction?

Best regards

Nuno


On Feb 17, 4:05 pm, Nuno Lopes <[email protected]> wrote:
> Hi all
>
> Let me clarify.
>
> Changing the state of an objA depends on the state of objB (some
> business rule on B). While objA is being persisted there must be a way
> to garantee that the state objB has not changed during the transaction
> (that the Test() still return true ). Otherwise you may be persisting
> objA when the business rule in objB is already failing (Test() is
> returning false).
>
> The code is just an example (pseudo code).
>
> // start tranasction
> A objA = (A) session.Load(typeof(A), aIDOfA);
> B objB = (B) session.Load(typeof(B), aIDOfB);
> a.DoSomeChanges(b);
> // end transaction
>
> On Class A
>
> void DoSomeChanges(B b)
> {
>     if (b.Test()
>        this.propA = 23;
>
> }
>
> On Class B we have
>
> bool Test()
> {
>     return this.propB == "Hello Word";
>
> }
>
> You see. When the DoSomeChanges is processed Test() is true. This
> implies that this.propB is equal to "Hello Word".
> But when A is being persisted to the database it might be the case
> that Test() is already failing (return false) since the value of propB
> in the db might be "Godbye Word" becouse meanwhile it was changed by
> another process.
>
> I know that we can specify an isolation level for the ADO.NET
> connections such as REPEATABLE READ (Specifies .....  that no other
> transactions can modify data that has been read by the current
> transaction until the current transaction completes.) This is the same
> as SELECT FOR UPDATE in some databases.
>
> But I would rather prefer to do this using pure Optimistic Locking.
> For that matter we need check if objB has been changed in the database
> even though the app didn't change it, this at the time the transaction
> ends (or data of objA is commited of flushed).
>
> What is the NHibernate soilution to this scenario without using the
> transaction isolation: REPEATABLE READ. This with minimal intrusion
> into the Domain Model?
>
> Thanks in advance for all the help.
>
> On Feb 17, 3:01 pm, Roger Kratz <[email protected]> wrote:
>
>
>
> > If I understand you correctly you want optimistic version control on 
> > aggregates rather than entities/dbrows?
>
> > It depends... In the app I'm working with right now we're always have 
> > bidirectional refs within an aggregates which make it quite easy/fast to 
> > find the aggregate root at persist time (interceptor/nh events) and flag 
> > this as dirty. On this root we have the version column (valid for hole 
> > aggregate). Works fine for us.
>
> > Leaving the nh world would give you alternatives like... Not changing child 
> > objects directly but through something that also knows about its root 
> > object. Or letting the child object inform its root when it's modified. If 
> > it suits you - one way could also be not involving nh at all.
>
> > /Roger
>
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]] On Behalf 
> > Of Nuno Lopes
> > Sent: den 17 februari 2009 13:52
> > To: nhusers
> > Subject: [nhusers] Objects State Validation && Business Rules in non 
> > Trivial Domain Models
>
> > Hello,
>
> > I have the following problem looking for a NHIbernate solution.
>
> > Suppose we have an object objA business rules depend on the state of
> > objB.
>
> > Say you have to classes A and B:
>
> > // start tranasction
> > A objA = (A) session.Get(typeof(A), aID);
> > B objB = (B) session.Get(typeof(B), aID);
> > a.DoSomeChanges(b);
> > // end transaction
>
> > The DoSomeChangesMethod of A does this:
>
> > void DoSomeChanges()
> > {
> >     if (b.Test()
> >        this.propA = 23;
> > }
>
> > The method Test() on B does this;
>
> > bool Test()
> > {
> >     return this.propB == "Hello Word";
> > }
>
> > Notice that objB state is not changed in this process so it is not
> > Dirty.
>
> > My problem is that when objA is persisnted it might be the case the
> > state of objB are no longer valid (its state in the DB was changed by
> > some other process also using NHibernate).
>
> > How can I force NHibernate to check if the state of objB was not
> > changed while saving objA (in a single transaction)?
>
> > As far as I understand every time an object is saved, its version is
> > increased. Also NHibernare rises an exception if the version of the
> > object being saved is too old in comparison with the one thet is
> > stored. It also does not save the object if the version is current.
>
> > If that is the case, I thought about forcing objB along with objectA
> > to be saved in order for its version to be checked. That way the state
> > of objB would be the most current. But I don't know how to do this
> > either.
>
> > I also would want to enforce this behaviour in the way that my code
> > above does not need to know that the state of objB need to be checked.
>
> > Anyway, what would you experience NHibernate user do in this case?
> > I'm sure it is not unique, probably NHibernate already deals with this
> > automatically, I just don't know.
>
> > Any help would be appreciated.
>
> > Nuno- Hide quoted text -
>
> > - Show quoted text -- Hide quoted text -
>
> - Show quoted text -

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"nhusers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/nhusers?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to