@Diego: If I understand you correctly: the basic model would be that you make all changes in the current session (in memory) and flush everything at the moment of commit. I've looked at Fabios ChinookWinForms example and he sets the FlushMode to never. This would allow the user to work without a transaction and this would leverage the client side ID assignment (HiLo/Guid).
What I would like help with is how to handle errors. When e.g. an entity the user has chosen at the start of a workflow has been removed/ changed. I understand NHibernate has versioning tools for this, and it is doable to actually verify the data is correct. But, when the data is not correct, what do I do then. I can hardly tell the user after half an hour of data entry "well, it seems you have chosen something invalid; bad luck; try again." This is why I'm looking at a repeatable read transaction mode. Another problem is that in my current model, I perform flushes during the execution of a workflow. An example: An entity is modified which impacts child records. These child records have a uniquely indexed order field which I need to re-sequence (child with index 2 becomes 1, and the child with index 1 becomes 2). Currently, I can only do this by making the mutation 1 -> 3; Flush; 2 -> 1; 3 -> 2. If I do not do the Flush, the first mutation is ignored and the moment the second mutation is flushed, I get a unique index error. What makes the above situation worse is that this happens while running a workflow. The first step is a maintenance screen on the parent entity, and the second screen is a maintenance screen on the child records. These all must have the correct state and a Cancel anywhere in the workflow must reverse all changes. Do you have suggestions for this specific cases? On Sep 14, 11:52 pm, Diego Mijelshon <[email protected]> wrote: > There are several patterns for long-running transactions/conversations. Just > make sure not to confuse those with NHibernate/DB transactions. > NH also has lots of tools for dealing with concurrency (versioning, locking, > refreshing and so on). > > Another pattern that helps dealing with long conversations and concurrency > is keeping everything in DTOs, then re-retrieving everything in a new > session when finishing the use case and applying the changes (everything in > a transaction). This also gives you a lot of control over conflict > resolution. > > Diego > > > > On Tue, Sep 14, 2010 at 17:51, pvginkel <[email protected]> wrote: > > About the Hi-Lo: I misinterpreted the mechanism. I read more about it > > and I will take a look at this. Looks interesting. > > > Concerning the transaction/session. My primary concern here is data > > consistency. Because the application is very data intensive and there > > is a real chance of multiple people working on the same data > > simultaneously, I worry about consistency between different users. If > > it would just be that the flush were in a transaction, it would be OK. > > What I am more interested in is stuff like repeatable reads. I have > > already moved query lookups (auto-complete and lookup forms) out of > > bound (separate thread with separate transactions and re-checking the > > selected data) to minimize the impact on the running transaction, but > > that still leaves the operational data. > > > On Sep 14, 8:22 pm, Diego Mijelshon <[email protected]> wrote: > > > Inline > > > > Diego > > > > On Tue, Sep 14, 2010 at 15:08, pvginkel <[email protected]> wrote: > > > > I am writing a framework for a rewrite of an existing application. We > > > > have a data model of around 900 tables with 11000 fields in total and > > > > databases approaching 120 GB in the field. The basic elements of my > > > > new implementation are WPF, NHibernate 3, C#, .NET 4.0, > > > > NHibernate.Validator and Spring. The application itself is very data/ > > > > transaction intensive and our largest installation has around 300 > > > > concurrent users. > > > > > A few things I would like feedback about are: > > > > > * Is Spring a good choice? Why should I choose a different one > > > > (Castle?). I do have problems with startup time, but I have been able > > > > to bring this back to around 14 seconds. I didn’t notice much > > > > difference between Spring and Castle though. Shorter startup times are > > > > of course welcome; > > > > They are pretty much the same; use whatever you're comfortable with. > > > > > * I am using Identity fields, but understand this isn't the best > > > > option. What viable alternative is there (HiLo does not sound like a > > > > good idea); > > > > Hilo is one of the best alternatives. In fact, it's one of the two > > > recommended* ones (the other is guid) > > > Care to describe why it "does not sound like a good idea" to you? > > > > *: recommended by me, upcoming blog post > > > > * Data display is done with short sessions, one per query. Data entry > > > > > on the other hand has one session/transaction for the entire duration > > > > of a workflow, which can take up to 10-20 minutes max (2-4 minutes is > > > > more usual). Are there alternatives to a session/transaction for this > > > > entire duration and how could I set this up? > > > > Session and transaction are not interchangeable terms. > > > It's ok to have a session open for the whole duration of a workflow; a > > > transaction is a problem (because it holds up resources) > > > The suggested pattern is CpBT (Conversation per Business Transaction); > > there > > > are samples in unhaddins, Fabio's blog, etc. > > > > > I am open to all and every input and would like to integrate ideas > > > > from people whom have been working longer, and have more experience, > > > > with NHibernate than I have :). > > > > > (B.t.w.: I know I’m in way over my head, but that’s the way I prefer > > > > it.) > > > > We always welcome people willing to learn :-) > > > -- > > 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]<nhusers%[email protected] > > > > > . > > For more options, visit this group at > >http://groups.google.com/group/nhusers?hl=en. -- 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.
