Fwd: AutoFlush not working anymore?

[Markus Zywitza]

I have verified against a plain test case that there is a problem
within ActiveRecord. I have verified that the test case works when
directly using an ISession instead of a SessionScope. I will add the
tests to AR this evening and try to find a solution on this.

IMO this is a showstopper for releasing 1.0. The behaviour is
inconsistant with NHibernate's and requires the user to flush manually
before every query.

I will open a Donjon issue as well, but Donjon doesn't behave
correctly on IE6, so I'll have to do that at home as well.

If you have any idea where to start looking, please tell.

-Markus

---------- Forwarded message ----------
From: Markus Zywitza <markus....@gmail.com>
Date: Aug 25, 2008 16:13
Subject: AutoFlush not working anymore?
To: castle-pro...@googlegroups.com

Hi all

I'm not sure where the problem lies, but I have massive problems when
I have locally edited objects, that there is no flush before those
objects are queried from database by another method.

Example

using (new SessionScope()){
Foo foo = ActiveRecordMediator<Foo>.FindFirst();
foo.Bar = 2;

Assert.AreEqual(1,ActiveRecordMediator<Foo>.Count(Expression.Eq("Bar",2)));
}

This example fails. When I read the NH docs correctly, NH should check
for changes to a foo before querying for other Foos and hence flush
automatically.

This is a contrived example. In my production code, I have currently a
lot of such calls in my repositories:

Foo[] GetFooByBar(int bar) {
SessionScope.Current.Flush();
return ActiveRecordMediator.FindAll(Expression.Eq("Bar",bar));
}

I don't like that workaround. Any comments on what I might be doing wrong here?

-Markus

[Rafael Teixeira]

AFAIK, flushing data is a programmer's responsibility as automatically flushing on every change costs a lot of performance.

I think, Monorail's ActiveRecord integration, helps the programmer a bit in that regard by having a session scope created for each request.
Also the Transaction Facility (not sure I'm remembering it right if it is a Facility or not), adds support for methods being a closed transaction (implicitly flushing data at the end if not rolled back).

That is the reason there are some method variants that also flush the changes like CreateAndFlush(), UpdateAndFlush(), etc...

Caching settings also affect this issue of changes-before-flushing-visibility, as NHibernate will try to reuse in-memory instances to fill out query requests.

All of that is from the top of my memory, so others may offer a more precise answer.

Anyway, I hope it helps,

--
Rafael "Monoman" Teixeira
---------------------------------------
"I myself am made entirely of flaws, stitched together with good intentions."
Augusten Burroughs

[Markus Zywitza]

NHibernate doesn't flush on every request, just when it detects that
dirty instances are part of a query. Having to flush explicitly is a
source of errors, since the application behaves differently with or
without SessionScopes. Sometimes, the use of scopes is not
controllable, i.e. in a domain model.

-Markus

[Simon Laroche]

I tried changing the flush mode of the session in the transactionscope to Auto and it fixed the autoflush when running a query. However it makes the ValidateIsUniqueWithinTransactionScope test in ValidationTestCase fail.

Simon

[Markus Zywitza]

I have been diving into details and located the problem: ActiveRecord
is stuck in NH1.2 regarding to session management. No session
management mechanism has been migrated to NH2.0.

The consequences on ad-hoc sessions (when using neither SessionScope
nor TransactionScope) are not visible because the session is flushed
and disposed immediately after the call, however we should implement
an implicit transaction here too to adhere to NH2.0 recommendations.

When using a SessionScope, the consequence is that FlushMode.Auto is
not working due to the lack of a transaction. I already fixed this by
adding a default transaction to every session stored in an
auto-flushing, non-transactional SessionScope. The behaviour of
SessionScope is therefore as before migration from NH1.2 to NH2.0.

The TransactionScope-behaviour has not changed. TransactionScope
implicitly sets the FlushMode to FlushMode.Commit. It has done so when
using NH1.2, so there is no breaking change here. However, I find it
very disturbing that code behaves differently when running w/o scope,
in session scope or in transaction scope. Remember that code cannot
always tell in which scope type it currently runs. The best example is
DDD: Some logic is in the domain layer, which uses repository
implementations in the persistence layer, but the unit of work (scope)
is controlled by the application layer. The first layer soesn't know
of scopes, the second has no control about them, and the third doesn't
know which code the first two use...

My proposal is therefore to break behaviour and set the FlushMode in
TransactionScope to Auto. Any other suggestions or comments?

-Markus

[Simon Laroche]

I agree with you about the flush mode within a transaction scope.

Should we set the flush mode to Auto or leave or value already set for the session?

I tried changing the flush mode to auto a test failes in the IsUniqueValidator stuff. I hacked it by setting the flush mode to never during that validation and reverting it to the previous value afterwards.

Simon

[Markus Zywitza]

I'll have a look at it. I made more changes to SessionScope that
currently breaks about 25 other tests, so I have to investigate that
further.

-Markus

[hammett]

I'm OK with whatever change that makes the behavior more predictable...

On Thu, Aug 28, 2008 at 2:13 AM, Markus Zywitza
<markus....@gmail.com> wrote:
> My proposal is therefore to break behaviour and set the FlushMode in
> TransactionScope to Auto. Any other suggestions or comments?

--
Cheers,
hammett
http://hammett.castleproject.org/

[Markus Zywitza]

The current behaviour is perfectly predictable: No flush unless
explicitly called or disposal of the scope. We could relabel that as a
feature...

Jokes aside, I'm currently stuck with this, having some tests throwing
exceptions from deep within NH. I will see what I can do, but it won't
be finished before early October.

-Markus

2008/9/7 hammett <ham...@gmail.com>: