Transaction Attribute?
5 views
Skip to first unread message
Jay Oliver
Mar 3, 2009, 4:59:21 PM3/3/09
to S#arp Architecture
Since it's required to use this attribute on every controller method
that changes the state of the database, but highly recommended to use
it on any method that accesses the database at all, does anything
think it might make sense to change this to work as an interceptor
instead?
The default behavior could be to start a transaction, but an attribute
could still be used to control the isolation level or opt out of any
transactions completely.
that changes the state of the database, but highly recommended to use
it on any method that accesses the database at all, does anything
think it might make sense to change this to work as an interceptor
instead?
The default behavior could be to start a transaction, but an attribute
could still be used to control the isolation level or opt out of any
transactions completely.
Billy
Mar 3, 2009, 5:06:39 PM3/3/09
to S#arp Architecture
Would you be able to provide a little more detail about the proposed
solution and the benefit it would provide?
Thanks!
Billy
solution and the benefit it would provide?
Thanks!
Billy
Jay Oliver
Mar 3, 2009, 5:40:13 PM3/3/09
to S#arp Architecture
Sure. For the sake of the rest of this post, let's assume the
following things:
The majority of controller actions involve going to the database in
one fashion or another.
Using a transaction is required all writes
Using a transaction is highly recommended for reads.
Under the current model, you'll be decorating most action methods with
the Transaction attribute. If you forget to do so, the default is to
not enlist in a transaction at all, which is terrible for writes and
less than optimal for reads.
Under an interceptor based model, you'd only have to decorate the
action methods where you wanted to change the isolation level or opt
out of the transaction completely. If you forget, the consequences are
creating a transaction you didn't need or a possible concurrency issue
created by using the wrong isolation level.
In my mind, the interceptor based model has better/safer default
behavior if you make a mistake. That makes me feel more comfortable,
especially this is an area you can't really be testing via unit tests.
I can provide a working example for Windsor - I don't know enough
about the other containers to know how easy/difficult it may be.
following things:
The majority of controller actions involve going to the database in
one fashion or another.
Using a transaction is required all writes
Using a transaction is highly recommended for reads.
Under the current model, you'll be decorating most action methods with
the Transaction attribute. If you forget to do so, the default is to
not enlist in a transaction at all, which is terrible for writes and
less than optimal for reads.
Under an interceptor based model, you'd only have to decorate the
action methods where you wanted to change the isolation level or opt
out of the transaction completely. If you forget, the consequences are
creating a transaction you didn't need or a possible concurrency issue
created by using the wrong isolation level.
In my mind, the interceptor based model has better/safer default
behavior if you make a mistake. That makes me feel more comfortable,
especially this is an area you can't really be testing via unit tests.
I can provide a working example for Windsor - I don't know enough
about the other containers to know how easy/difficult it may be.
Billy
Mar 3, 2009, 10:49:37 PM3/3/09
to S#arp Architecture
Hi Jay,
I see where you're going with this. If you could provide a working
example, it would be very helpful in trying it out in various
scenarios.
Thank you,
Billy
> > > transactions completely.- Hide quoted text -
>
> - Show quoted text -
I see where you're going with this. If you could provide a working
example, it would be very helpful in trying it out in various
scenarios.
Thank you,
Billy
>
> - Show quoted text -
Reply all
Reply to author
Forward
0 new messages