The [AspectBehavior(OpenTransaction = true)] does not work as expected : When entering a method with this attribute, I get a the following Exception :
Unable to process operation without a transaction. Use Transaction.Open(...) to open it.

Apparently, the attribute does not open any transaction. Thank you for your feedback
Best regards,

Auguste

Updated at 14.09.2009 14:46:29

Hi,

Thank you for your feedback

In this case [AspectBehavior] really shouldn't change anything:
[...]
Could you publish a complete stack trace? Does removal of attribute change the behavior?

No, the removal of the attribute does not change anything indeed.
In fact, the bug is easy to reproduce. Please find hereafter the complete code needed to reproduce the bug. Version used is the latest nightly build available on 2009-09-11

Updated at 15.09.2009 16:53:03

In this case [AspectBehavior] really shouldn't change anything:
- You can consider its default property values for any public SessionBound method are OpenTransaction = true, OpenSession = true

Given Otto's fix, I find it confusing that SessionOptions.AutoTransactions is off by default.

@Dimitri : I agree with you. Moreover, I find it easier to set the set options in DomainConfiguration : creating a new SessionConfiguration and adding it to DomainConfiguration.Sessions is not very straightforward. Anyway, it is easy use [AspectBehavior] to locally change the transactions behavior.

otto wrote:

Hello Auguste,

I am also a user of DO4.
As far as I know public methods/properties on a SessionBound derived class (Entity is that) need not be decorated with AspectBehavior, because they are automatically decorated by PostSharp at compile-time, so they will open a transaction if there is no one yet.
Could you try it this way?
Despite of this, the problem you showed will be probably answered or investigated.

Best regards,
Otto

Alex (Xtensive) wrote:

In this case [AspectBehavior] really shouldn't change anything:

You can consider its default property values for any public SessionBound method are OpenTransaction = true, OpenSession = true

And on contrary, for any other method they are OpenTransaction = false, OpenSession = false

So that's why applying it in your case must not affect on anything. Probably, such "design" of [AspectBehavior] is wrong - I'll think how to change this to make it more clear.

Returning back you your issue: what's really strange is that there is no transaction. It must be.

Could you publish a complete stack trace? Does removal of attribute change the behavior?

The simplest way to check if method is really transactional is to study its C# code by .NET Reflector. There must be calls to TransactionalAspect.

Anyway, for now it looks much like a bug. The only possible your own error I imagine is case when this exception is thrown by some other code.

Alex (Xtensive) wrote:

Thank you a lot for such a comprehensive bug report - most likely, we'll fix the issue tomorrow.

If it will be possible, I will try to send you the most current build (there are few more important fixes). As you know, we don't update nightly builds for now, since we significantly change build process (no more necessity to install PostSharp + no more installation into GAC). So if I'll be able to finish this tomorrow, I'll send you new installer (I'm responsible for this). Otherwise I can send the binaries...

The name "Default" is important, because this indicates that this sessionconfig will be used by default in your sessions.

BTW in sessionconfig you can set other things like cache size and so on.

Could you try this?

Alex (Xtensive) wrote:

Otto, thanks a lot for helping us. I fully forgot about this option.

Yes, by default automatic transactions are turned off. I.e. we always activate a Session (this.Session==Session.Current inside aspected SessionBound methods), but not always create a transaction. This depends on SessionOptions.

By default automatic transactions are off: we did this to ensure you will make a decision to use them or not by your own.

otto wrote:

I think the exception message should really mention this.
And in the manual in the configuration/session part these options and other configuration details should be described. Including these special names ("Default", "Service", "KeyGenerator", "System")
After this I think it is not needed to turn it on by default, because everybody can setup his own default sessionconfig.

Dmitri Maximov (Xtensive) wrote:

As for me, the configuration parameter should be contained in DomainConfiguration rather than in SessionConfiguration as it really influences the way a developer writes code for operations with transactional members (properties and methods). I mean the absence of necessity to write Transaction.Open regions.

If a developer prefers to use AutoTransactions = On mode, then he probably prefers to use this mode in EVERY session in his Domain. But current implementation enforces him to set this option manually in every SessionConfiguration instance. In simple scenarios this could be done by setting this option for Default SessionConfiguration, but only for simple scenarios with a few or even only one SessionConfiguration.

Alex (Xtensive) wrote:

Actually we're thinking about removing this option (AutoTransactions) at all... There is just one reason for disabling it: to identify all the places where transactions are created automatically rather than manually.

So likely, it will be a better idea to e.g. optionally log such transactions (it will be cheap taking into account logging performance) + add corresponding performance counters.

Please start posting your answer anonymously - your answer will be saved within the current session and published after you log in or create a new account. Please try to give a substantial answer, for discussions, please use comments and please do remember to vote (after you log in)!