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...
otto wrote:
This part of the code fails:
if (autoTransaction && !Configuration.AllowsAutoTransactions)
throw new InvalidOperationException(Strings.ExTransactionRequired);
So I think the problem is that SessionConfiguration.AllowsAutoTransactions is false.
You should create a SessionConfiguration in DomainConfig like this:
var sc = new SessionConfiguration("Default");
sc.AllowsAutoTransactions = true;
domainConfig.Sessions.Add(sc);
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.
Alex (Xtensive) wrote:
Related issues:
answered
Sep 11 '09 at 20:35
Editor
46●156●156●157