About 1st-level-cache: Each session has one (except for stateless sessions that don't exist currently in AR). When code executes using the same session scope, it shares one session and therefore one 1st-level-cache. All entities that NH persists, are put into this cache. Now, if you load an entity in one session and the session ends, the entity is transient because it is not within a sessions 1st-level-cache. If you call save, it gets connected to another session. Because it is not in this session's cache, the sesson cannot determine whether the entity is dirty or not, because it doesn't have the entity's original state in its cache. It therefore assumes that the entity has to be updated. The same is true for all cascaded collections and associations. That means that reading and saving an entity without having a sessionscope in common for both operations leads to an update regardless whether the entity was changed in between or not.
On IDENTITY: NH has to determine an entities PK when it is added to its cache (in AR this means, the call to Save()). Without the PK, it would not be possible to get the associations right. As a result, NH has to hit the DB and call INSERT on it to get the PK when it is an identity field. But it is no complete flush, so there is for example no cascade. The common symptom is that you have to call SaveAndFlush() for associated entities which should normally be handled by cascading, but are not due to the early insert. -Markus 2009/5/8 Flominator <[email protected]>: > > Hi Markus, > > thanks for all this clarification. > > I can't wait to read the other two posts. > > Why are those default IDs bad? What do they help in regard to my > original question #2? > > What about the shared 1st level cache you mentioned earlier? > > Best regards and a nice weekend, > > Flo > > On May 6, 11:44 am, Markus Zywitza <[email protected]> wrote: >> Hi Flo >> >> answers inline >> >> 2009/5/6 Flominator <[email protected]>:> 1. Is there any way to stop >> NHibernate from opening too many >> > sessions? >> >> AR by default opens a NH session per operation. NH opens a db >> connection per session, but disconnects and reconnects it per >> operation. >> If you use a SessionScope, only one NH session is used for all >> operations within the scope and thus NH only opens one db connection. >> >> > 2. What about batching more queries into one transaction than I have >> > now? >> >> Put them in one TransactionScope instead of a SessionScope. Call >> scope.VoteCommit() or scope.VoteRollback() within the scope. >> >> > 3. Does flushing a SessionScope mean that the SessionScope is gone? >> >> No, it just forces NH to write changes to the db, instead of delaying >> them (all changes are then written in one batch, improving db >> performance). >> >> > 4. What is the relationship between sessions in NHibernate, >> > transactions in NHibernate, SessionScopes in AR and TransactionScopes >> > in AR? >> >> Plug (shameless):I posted two articles >> onhttp://mortslikeus.blogspot.com413and I have prepared two more that >> exlain it in detail. >> In short: >> SessionScope -> one session with implicit transaction >> Nested SessionScopes -> evil >> TransactionScope -> add explicit transaction to outer SessionScope or >> create a new one with explicit transaction >> Nested TransactionScopes -> avoid, use only with inheriting outer >> scopes. NH cannot nest transactions within on session, thus multiple >> nested transactions force us to create multiple SessionScopes under >> the covers. >> >> > 5. I use ID fields with the AR default behavior on Firebird or MSSQL >> > server. >> >> That's bad. Try to use HiLo or GuidComb instead if possible. See teh >> following posts for >> explanations:http://fabiomaulo.blogspot.com/2008/12/identity-never-ending-story.html414http://fabiomaulo.blogspot.com/2009/02/nh210-new-generators.html415http://fabiomaulo.blogspot.com/2009/02/nh210-generators-behavior-expl...416 > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Castle Project Users" 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/castle-project-users?hl=en -~----------~----~----~----~------~----~------~--~---
