you are exactly correct. by using a proxy to save the state of the entity inside of it, the tracking of you're entity's state is no longer restricted to a specific session, meaning you don't have to refetch the entity within the current session, but can just attach (using the saveOrUpdate method) a previously fetched entity (or entities) to the current session, and the entity's state is being kept. Also, lazy loading is still being enabled... so you can have session per view and just attach the working entity each time a session is being opened.
On Wed, Sep 15, 2010 at 2:31 PM, pvginkel <[email protected]> wrote: > @matanzg: I'm not quite sure how this would work. I would suspect a > second level cache is limited to the work station of the end user, so > this does not solve changes in the database while a workflow is > running. > > Could you give an example of how such system would improve on my > situation? Specifically, what problem does it solve? > > On Sep 15, 2:29 pm, matanzg <[email protected]> wrote: > > Why not use second level cache for data consistency? > > > > On 15 ספטמבר, 08:13, pvginkel <[email protected]> wrote: > > > > > > > > > @nadav s: If I understand this correctly, this would allow me to re- > > > use the same entity instance throughout the client application over > > > different sessions/workflows/views/threads. Is that correct, or am I > > > missing something? > > > > > On Sep 15, 7:15 am, nadav s <[email protected]> wrote: > > > > > > if you don't want to use a DTO and prefere to use you're entity, you > wanna > > > > fully leaverage the lazy loading features, you can read thishttp:// > www.codeproject.com/KB/library/StatefulEntityProxies.aspx > > > > > > On Wed, Sep 15, 2010 at 6:08 AM, Dietrich <[email protected]> > wrote: > > > > > I learned it the hard way- use the unit of work pattern and > abstract > > > > > away all the concept of a session/transaction from the front end. > It > > > > > becomes quite a headache. There are a few UoW implementations out > > > > > there to look at. I would also advise the liberal use of the > > > > > repository pattern and having a rule for yourself never to touch th > > > > > hibernate namespace in form. > > > > > > > On Sep 14, 2:08 pm, 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; > > > > > > > > * 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); > > > > > > > > * 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? > > > > > > > > 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.) > > > > > > > -- > > > > > 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]> > <nhusers%[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]<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.
