Hi Flo
2009/5/13 Flominator <flomina...@gmx.net>:
>
>> 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 <markus.zywi...@gmail.com> 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 <flomina......@gmx.net>:
>>
>>
>>
>> > 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 <markus.zywi......@gmail.com> wrote:
>> >> Hi Flo
>>
>> >> answers inline
>>
>> >> 2009/5/6 Flominator <flomina.........@gmx.net>:> 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.com413and467I 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.ht...468
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Castle Project Users" group.
To post to this group, send email to castle-project-users@googlegroups.com
To unsubscribe from this group, send email to
castle-project-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/castle-project-users?hl=en
-~----------~----~----~----~------~----~------~--~---
