Thanks for your support.

Tried to evict the Measurand within the transaction => exception on
disposal

The other solution would compile, since it didn't recognize "typeof
(ActiveRecord)". I then tried it with typeof(Measurand) and typeof
(ActiveRecordBase) but both brought no Measurand entries to the
database :(

I checked with NHProf and found all relevant queries listed there. It
looks like the statelessSession wasn't committed. Any ideas?

Regards,

Flo


On 14 Mai, 09:23, Markus Zywitza <[email protected]> wrote:
> Hi Flo
>
> 2009/5/13 Flominator <[email protected]>:
>
> >> All entities that NH persists,
> >> are put into this cache.
>
> > Does that mean that NH caches all my 18 million objects after they
> > were created and saved via ARMediator?
>
> Yes, exactly.
>
> > Is there a way to remove objects from the cache after they were
> > created and saved?
>
> Get the session and evict them from it.
> ActiveRecordMediatior.GetSessionFactoryHolder().CreateSession(typeof(Measurand)).Evict(measurand);
>
> > Could I make created and saved objects in a collection lazy without
> > loading them again?
>
> I fear that you cannot. The collection is for holding all referenced
> objects, lazy or not. I don't think you can go anywhere without
> removing that collection.
>
> > I just want to create and save my objects. The measurands are not
> > changed after they were once created and saved.
>
> I'm working on StatelessSessionScope, which could help in your case.
> Until then, try the following instead of using ActiveRecordMediator:
>
> using (var statelessSession =
> ActiveRecordMediator.GetSessionFactoryHolder().GetSessionFactory(typeof(ActiveRecord)).OpenStatelessSession())
> using (var tx = statelessSession.BeginTransaction())
> {
>   // Instead of ActiveRecordMediator.Save(measurand);
>   statelessSession.Insert(measurand);
>
> }
>
> -Markus
>
>
>
> > Thank you very much for your patience.
>
> > Flo
>
> > On May 10, 8:27 pm, Markus Zywitza <[email protected]> wrote:
> >> 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.com413and467I561have 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.ht...562
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to