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.
