sounds like alot of code which could be minimized...I've had an idea,
only didnt test till now that Session.Transaction.IsActive could be
the key, and this morning read an article:
> sounds like alot of code which could be minimized...I've had an idea,
> only didnt test till now that Session.Transaction.IsActive could be
> the key, and this morning read an article:
> sounds like alot of code which could be minimized...I've had an idea,
> only didnt test till now that Session.Transaction.IsActive could be
> the key, and this morning read an article:
> > sounds like alot of code which could be minimized...I've had an idea,
> > only didnt test till now that Session.Transaction.IsActive could be
> > the key, and this morning read an article:
> > sounds like alot of code which could be minimized...I've had an idea,
> > only didnt test till now that Session.Transaction.IsActive could be
> > the key, and this morning read an article:
> > (this, of course is only valid for single operation transactions).
> > What do you think?
> > Vladan
-- Tom Cabanski
Vice President of Technology
Onpoint On Demand (Houston Office)
4801 Woodway Drive
Suite 300 East
Houston, TX 77056
Direct: 713-962-2638
http://www.onpointod.com
The transaction support is something that I think needs some love. At the
moment, transaction support is only at the controller level. I.e. you can't
make a service call transactional. Unless you call out to the DbContext
method on a repository which I think is a leaky abstraction. Even at the
controller level, you still need to manually rollback a database transaction
if anything goes wrong.
I like the idea of everything being transactional by default and maybe
explicitly specifying when you *don't* want to use one.
On Tue, Sep 22, 2009 at 7:38 AM, Tom Cabanski <t...@cabanski.com> wrote:
> Isn't the Transaction attribute in SharpArch exactly what you are talking
> about?
> On Tue, Sep 22, 2009 at 6:04 AM, Vladan Strigo <vla...@strigo.net> wrote:
>> > sounds like alot of code which could be minimized...I've had an idea,
>> > only didnt test till now that Session.Transaction.IsActive could be
>> > the key, and this morning read an article:
On Tue, Sep 22, 2009 at 14:54, Kyle Baley <k...@baley.org> wrote:
> The transaction support is something that I think needs some love. At the
> moment, transaction support is only at the controller level. I.e. you can't
> make a service call transactional. Unless you call out to the DbContext
> method on a repository which I think is a leaky abstraction. Even at the
> controller level, you still need to manually rollback a database transaction
> if anything goes wrong.
> I like the idea of everything being transactional by default and maybe
> explicitly specifying when you *don't* want to use one.
> On Tue, Sep 22, 2009 at 7:38 AM, Tom Cabanski <t...@cabanski.com> wrote:
>> Isn't the Transaction attribute in SharpArch exactly what you are talking
>> about?
>> On Tue, Sep 22, 2009 at 6:04 AM, Vladan Strigo <vla...@strigo.net>wrote:
>>> > I've been thinking about this for a while...in NH its recommended to
>>> > put in transaction even the read operations. But to do something like:
>>> > sounds like alot of code which could be minimized...I've had an idea,
>>> > only didnt test till now that Session.Transaction.IsActive could be
>>> > the key, and this morning read an article:
Which part? Making the service call transactional or making everything
transactional by default? In either case, is this something that should be
incorporated into S#arp?
On Tue, Sep 22, 2009 at 8:55 AM, Simone Busoli <simone.bus...@gmail.com>wrote:
> Kyle, this is easilly accomplished with windsor and interceptors.
> On Tue, Sep 22, 2009 at 14:54, Kyle Baley <k...@baley.org> wrote:
>> The transaction support is something that I think needs some love. At the
>> moment, transaction support is only at the controller level. I.e. you can't
>> make a service call transactional. Unless you call out to the DbContext
>> method on a repository which I think is a leaky abstraction. Even at the
>> controller level, you still need to manually rollback a database transaction
>> if anything goes wrong.
>> I like the idea of everything being transactional by default and maybe
>> explicitly specifying when you *don't* want to use one.
>> On Tue, Sep 22, 2009 at 7:38 AM, Tom Cabanski <t...@cabanski.com> wrote:
>>> Isn't the Transaction attribute in SharpArch exactly what you are talking
>>> about?
>>> On Tue, Sep 22, 2009 at 6:04 AM, Vladan Strigo <vla...@strigo.net>wrote:
>>>> > I've been thinking about this for a while...in NH its recommended to
>>>> > put in transaction even the read operations. But to do something like:
>>>> > sounds like alot of code which could be minimized...I've had an idea,
>>>> > only didnt test till now that Session.Transaction.IsActive could be
>>>> > the key, and this morning read an article:
The first part. BTW, transaction boundaries should be, well, at the
boundaries, therefore on your controllers or web service endpoints.
WRT everything transactional by default I don't think it should be a part of
the project.
On Tue, Sep 22, 2009 at 15:00, Kyle Baley <k...@baley.org> wrote:
> Which part? Making the service call transactional or making everything
> transactional by default? In either case, is this something that should be
> incorporated into S#arp?
> On Tue, Sep 22, 2009 at 8:55 AM, Simone Busoli <simone.bus...@gmail.com>wrote:
>> Kyle, this is easilly accomplished with windsor and interceptors.
>> On Tue, Sep 22, 2009 at 14:54, Kyle Baley <k...@baley.org> wrote:
>>> The transaction support is something that I think needs some love. At the
>>> moment, transaction support is only at the controller level. I.e. you can't
>>> make a service call transactional. Unless you call out to the DbContext
>>> method on a repository which I think is a leaky abstraction. Even at the
>>> controller level, you still need to manually rollback a database transaction
>>> if anything goes wrong.
>>> I like the idea of everything being transactional by default and maybe
>>> explicitly specifying when you *don't* want to use one.
>>> On Tue, Sep 22, 2009 at 7:38 AM, Tom Cabanski <t...@cabanski.com> wrote:
>>>> Isn't the Transaction attribute in SharpArch exactly what you are
>>>> talking about?
>>>> On Tue, Sep 22, 2009 at 6:04 AM, Vladan Strigo <vla...@strigo.net>wrote:
>>>>> > I've been thinking about this for a while...in NH its recommended to
>>>>> > put in transaction even the read operations. But to do something
>>>>> like:
>>>>> > sounds like alot of code which could be minimized...I've had an idea,
>>>>> > only didnt test till now that Session.Transaction.IsActive could be
>>>>> > the key, and this morning read an article:
That's a good point about it being at the boundaries. I can't think of an
example of where I'd like to make the service call transactional but not the
controller method.
Then again, are transactions typically part of the business rules? I.e. If
we want three things saved in a transaction, should it be closer to the
domain?
On Tue, Sep 22, 2009 at 9:02 AM, Simone Busoli <simone.bus...@gmail.com>wrote:
> The first part. BTW, transaction boundaries should be, well, at the
> boundaries, therefore on your controllers or web service endpoints.
> WRT everything transactional by default I don't think it should be a part
> of the project.
> On Tue, Sep 22, 2009 at 15:00, Kyle Baley <k...@baley.org> wrote:
>> Which part? Making the service call transactional or making everything
>> transactional by default? In either case, is this something that should be
>> incorporated into S#arp?
>> On Tue, Sep 22, 2009 at 8:55 AM, Simone Busoli <simone.bus...@gmail.com>wrote:
>>> Kyle, this is easilly accomplished with windsor and interceptors.
>>> On Tue, Sep 22, 2009 at 14:54, Kyle Baley <k...@baley.org> wrote:
>>>> The transaction support is something that I think needs some love. At
>>>> the moment, transaction support is only at the controller level. I.e. you
>>>> can't make a service call transactional. Unless you call out to the
>>>> DbContext method on a repository which I think is a leaky abstraction. Even
>>>> at the controller level, you still need to manually rollback a database
>>>> transaction if anything goes wrong.
>>>> I like the idea of everything being transactional by default and maybe
>>>> explicitly specifying when you *don't* want to use one.
>>>> On Tue, Sep 22, 2009 at 7:38 AM, Tom Cabanski <t...@cabanski.com> wrote:
>>>>> Isn't the Transaction attribute in SharpArch exactly what you are
>>>>> talking about?
>>>>> On Tue, Sep 22, 2009 at 6:04 AM, Vladan Strigo <vla...@strigo.net>wrote:
>>>>>> > I've been thinking about this for a while...in NH its recommended to
>>>>>> > put in transaction even the read operations. But to do something
>>>>>> like:
>>>>>> > sounds like alot of code which could be minimized...I've had an
>>>>>> idea,
>>>>>> > only didnt test till now that Session.Transaction.IsActive could be
>>>>>> > the key, and this morning read an article:
I don't see them as part of the business rules, but at times there's
something that makes me think about transactions when I'm into the domain.
Not everything you are doing might be transactional, think about email
notifications.
If you need to confirm a user about its registration, you might:
- register the user, but fail to send the notification -> the transaction is
rolled back and nothing happens
- send the notification, but fail to save the user -> the transaction is
rolled back but the email has already been sent
I think an ideal way to manage these things is to have non transactional
resources behave like transactional ones. In the example above
- even if the notification fails, retry until it succeeds and therefore
don't rollback the transaction
- if the database save doesn't succeed, "undo" the send
this can be accomplished in several ways, of which I don't know which are
the best ones. Among them asynchronous messaging and out of process batch
operations.
On Tue, Sep 22, 2009 at 16:55, Kyle Baley <k...@baley.org> wrote:
> That's a good point about it being at the boundaries. I can't think of an
> example of where I'd like to make the service call transactional but not the
> controller method.
> Then again, are transactions typically part of the business rules? I.e. If
> we want three things saved in a transaction, should it be closer to the
> domain?
> On Tue, Sep 22, 2009 at 9:02 AM, Simone Busoli <simone.bus...@gmail.com>wrote:
>> The first part. BTW, transaction boundaries should be, well, at the
>> boundaries, therefore on your controllers or web service endpoints.
>> WRT everything transactional by default I don't think it should be a part
>> of the project.
>> On Tue, Sep 22, 2009 at 15:00, Kyle Baley <k...@baley.org> wrote:
>>> Which part? Making the service call transactional or making everything
>>> transactional by default? In either case, is this something that should be
>>> incorporated into S#arp?
>>> On Tue, Sep 22, 2009 at 8:55 AM, Simone Busoli <simone.bus...@gmail.com>wrote:
>>>> Kyle, this is easilly accomplished with windsor and interceptors.
>>>> On Tue, Sep 22, 2009 at 14:54, Kyle Baley <k...@baley.org> wrote:
>>>>> The transaction support is something that I think needs some love. At
>>>>> the moment, transaction support is only at the controller level. I.e. you
>>>>> can't make a service call transactional. Unless you call out to the
>>>>> DbContext method on a repository which I think is a leaky abstraction. Even
>>>>> at the controller level, you still need to manually rollback a database
>>>>> transaction if anything goes wrong.
>>>>> I like the idea of everything being transactional by default and maybe
>>>>> explicitly specifying when you *don't* want to use one.
>>>>> On Tue, Sep 22, 2009 at 7:38 AM, Tom Cabanski <t...@cabanski.com>wrote:
>>>>>> Isn't the Transaction attribute in SharpArch exactly what you are
>>>>>> talking about?
>>>>>> On Tue, Sep 22, 2009 at 6:04 AM, Vladan Strigo <vla...@strigo.net>wrote:
>>>>>>> > I've been thinking about this for a while...in NH its recommended
>>>>>>> to
>>>>>>> > put in transaction even the read operations. But to do something
>>>>>>> like:
>>>>>>> > sounds like alot of code which could be minimized...I've had an
>>>>>>> idea,
>>>>>>> > only didnt test till now that Session.Transaction.IsActive could be
>>>>>>> > the key, and this morning read an article:
> I don't see them as part of the business rules, but at times there's
> something that makes me think about transactions when I'm into the domain.
> Not everything you are doing might be transactional, think about email
> notifications.
> If you need to confirm a user about its registration, you might:
> - register the user, but fail to send the notification -> the transaction
> is rolled back and nothing happens
> - send the notification, but fail to save the user -> the transaction is
> rolled back but the email has already been sent
> I think an ideal way to manage these things is to have non transactional
> resources behave like transactional ones. In the example above
> - even if the notification fails, retry until it succeeds and therefore
> don't rollback the transaction
> - if the database save doesn't succeed, "undo" the send
> this can be accomplished in several ways, of which I don't know which are
> the best ones. Among them asynchronous messaging and out of process batch
> operations.
> On Tue, Sep 22, 2009 at 16:55, Kyle Baley <k...@baley.org> wrote:
>> That's a good point about it being at the boundaries. I can't think of an
>> example of where I'd like to make the service call transactional but not the
>> controller method.
>> Then again, are transactions typically part of the business rules? I.e. If
>> we want three things saved in a transaction, should it be closer to the
>> domain?
>> On Tue, Sep 22, 2009 at 9:02 AM, Simone Busoli <simone.bus...@gmail.com>wrote:
>>> The first part. BTW, transaction boundaries should be, well, at the
>>> boundaries, therefore on your controllers or web service endpoints.
>>> WRT everything transactional by default I don't think it should be a part
>>> of the project.
>>> On Tue, Sep 22, 2009 at 15:00, Kyle Baley <k...@baley.org> wrote:
>>>> Which part? Making the service call transactional or making everything
>>>> transactional by default? In either case, is this something that should be
>>>> incorporated into S#arp?
>>>> On Tue, Sep 22, 2009 at 8:55 AM, Simone Busoli <simone.bus...@gmail.com
>>>> > wrote:
>>>>> Kyle, this is easilly accomplished with windsor and interceptors.
>>>>> On Tue, Sep 22, 2009 at 14:54, Kyle Baley <k...@baley.org> wrote:
>>>>>> The transaction support is something that I think needs some love. At
>>>>>> the moment, transaction support is only at the controller level. I.e. you
>>>>>> can't make a service call transactional. Unless you call out to the
>>>>>> DbContext method on a repository which I think is a leaky abstraction. Even
>>>>>> at the controller level, you still need to manually rollback a database
>>>>>> transaction if anything goes wrong.
>>>>>> I like the idea of everything being transactional by default and maybe
>>>>>> explicitly specifying when you *don't* want to use one.
>>>>>> On Tue, Sep 22, 2009 at 7:38 AM, Tom Cabanski <t...@cabanski.com>wrote:
>>>>>>> Isn't the Transaction attribute in SharpArch exactly what you are
>>>>>>> talking about?
>>>>>>> On Tue, Sep 22, 2009 at 6:04 AM, Vladan Strigo <vla...@strigo.net>wrote:
>>>>>>>> > I've been thinking about this for a while...in NH its recommended
>>>>>>>> to
>>>>>>>> > put in transaction even the read operations. But to do something
>>>>>>>> like:
>>>>>>>> > sounds like alot of code which could be minimized...I've had an
>>>>>>>> idea,
>>>>>>>> > only didnt test till now that Session.Transaction.IsActive could
>>>>>>>> be
>>>>>>>> > the key, and this morning read an article:
I've run across this exact same scenario and my solution was to use
the System.TransactionScope to wrap the database and email interaction
across one distributed transaction. I believe that
System.TransactionScope uses MSDTC under the hood, which coordinates
with database and non-database resources alike, such as an smtp
server.
I've pondered the idea of extending the [Transaction] attribute so
that it uses TransactionScope instead of just the NHibernate one. If
I'm not mistaken, an ADO.NET connection will automatically work within
the context of an MSDTC transaction...
On Sep 22, 8:47 am, Simone Busoli <simone.bus...@gmail.com> wrote:
> I don't see them as part of the business rules, but at times there's
> something that makes me think about transactions when I'm into the domain.
> Not everything you are doing might be transactional, think about email
> notifications.
> If you need to confirm a user about its registration, you might:
> - register the user, but fail to send the notification -> the transaction is
> rolled back and nothing happens
> - send the notification, but fail to save the user -> the transaction is
> rolled back but the email has already been sent
> I think an ideal way to manage these things is to have non transactional
> resources behave like transactional ones. In the example above
> - even if the notification fails, retry until it succeeds and therefore
> don't rollback the transaction
> - if the database save doesn't succeed, "undo" the send
> this can be accomplished in several ways, of which I don't know which are
> the best ones. Among them asynchronous messaging and out of process batch
> operations.
> On Tue, Sep 22, 2009 at 16:55, Kyle Baley <k...@baley.org> wrote:
> > That's a good point about it being at the boundaries. I can't think of an
> > example of where I'd like to make the service call transactional but not the
> > controller method.
> > Then again, are transactions typically part of the business rules? I.e. If
> > we want three things saved in a transaction, should it be closer to the
> > domain?
> > On Tue, Sep 22, 2009 at 9:02 AM, Simone Busoli <simone.bus...@gmail.com>wrote:
> >> The first part. BTW, transaction boundaries should be, well, at the
> >> boundaries, therefore on your controllers or web service endpoints.
> >> WRT everything transactional by default I don't think it should be a part
> >> of the project.
> >> On Tue, Sep 22, 2009 at 15:00, Kyle Baley <k...@baley.org> wrote:
> >>> Which part? Making the service call transactional or making everything
> >>> transactional by default? In either case, is this something that should be
> >>> incorporated into S#arp?
> >>> On Tue, Sep 22, 2009 at 8:55 AM, Simone Busoli <simone.bus...@gmail.com>wrote:
> >>>> Kyle, this is easilly accomplished with windsor and interceptors.
> >>>> On Tue, Sep 22, 2009 at 14:54, Kyle Baley <k...@baley.org> wrote:
> >>>>> The transaction support is something that I think needs some love. At
> >>>>> the moment, transaction support is only at the controller level. I.e. you
> >>>>> can't make a service call transactional. Unless you call out to the
> >>>>> DbContext method on a repository which I think is a leaky abstraction. Even
> >>>>> at the controller level, you still need to manually rollback a database
> >>>>> transaction if anything goes wrong.
> >>>>> I like the idea of everything being transactional by default and maybe
> >>>>> explicitly specifying when you *don't* want to use one.
> >>>>> On Tue, Sep 22, 2009 at 7:38 AM, Tom Cabanski <t...@cabanski.com>wrote:
> >>>>>> Isn't the Transaction attribute in SharpArch exactly what you are
> >>>>>> talking about?
> >>>>>> On Tue, Sep 22, 2009 at 6:04 AM, Vladan Strigo <vla...@strigo.net>wrote:
> >>>>>>> > I've been thinking about this for a while...in NH its recommended
> >>>>>>> to
> >>>>>>> > put in transaction even the read operations. But to do something
> >>>>>>> like:
> >>>>>>> > sounds like alot of code which could be minimized...I've had an
> >>>>>>> idea,
> >>>>>>> > only didnt test till now that Session.Transaction.IsActive could be
> >>>>>>> > the key, and this morning read an article:
> I've run across this exact same scenario and my solution was to use
> the System.TransactionScope to wrap the database and email interaction
> across one distributed transaction. I believe that
> System.TransactionScope uses MSDTC under the hood, which coordinates
> with database and non-database resources alike, such as an smtp
> server.
> I've pondered the idea of extending the [Transaction] attribute so
> that it uses TransactionScope instead of just the NHibernate one. If
> I'm not mistaken, an ADO.NET connection will automatically work within
> the context of an MSDTC transaction...
> On Sep 22, 8:47 am, Simone Busoli <simone.bus...@gmail.com> wrote:
>> I don't see them as part of the business rules, but at times there's
>> something that makes me think about transactions when I'm into the domain.
>> Not everything you are doing might be transactional, think about email
>> notifications.
>> If you need to confirm a user about its registration, you might:
>> - register the user, but fail to send the notification -> the transaction
>> is
>> rolled back and nothing happens
>> - send the notification, but fail to save the user -> the transaction is
>> rolled back but the email has already been sent
>> I think an ideal way to manage these things is to have non transactional
>> resources behave like transactional ones. In the example above
>> - even if the notification fails, retry until it succeeds and therefore
>> don't rollback the transaction
>> - if the database save doesn't succeed, "undo" the send
>> this can be accomplished in several ways, of which I don't know which are
>> the best ones. Among them asynchronous messaging and out of process batch
>> operations.
>> On Tue, Sep 22, 2009 at 16:55, Kyle Baley <k...@baley.org> wrote:
>> > That's a good point about it being at the boundaries. I can't think of
>> > an
>> > example of where I'd like to make the service call transactional but not
>> > the
>> > controller method.
>> > Then again, are transactions typically part of the business rules? I.e.
>> > If
>> > we want three things saved in a transaction, should it be closer to the
>> > domain?
>> > On Tue, Sep 22, 2009 at 9:02 AM, Simone Busoli
>> > <simone.bus...@gmail.com>wrote:
>> >> The first part. BTW, transaction boundaries should be, well, at the
>> >> boundaries, therefore on your controllers or web service endpoints.
>> >> WRT everything transactional by default I don't think it should be a
>> >> part
>> >> of the project.
>> >> On Tue, Sep 22, 2009 at 15:00, Kyle Baley <k...@baley.org> wrote:
>> >>> Which part? Making the service call transactional or making everything
>> >>> transactional by default? In either case, is this something that
>> >>> should be
>> >>> incorporated into S#arp?
>> >>> On Tue, Sep 22, 2009 at 8:55 AM, Simone Busoli
>> >>> <simone.bus...@gmail.com>wrote:
>> >>>> Kyle, this is easilly accomplished with windsor and interceptors.
>> >>>> On Tue, Sep 22, 2009 at 14:54, Kyle Baley <k...@baley.org> wrote:
>> >>>>> The transaction support is something that I think needs some love.
>> >>>>> At
>> >>>>> the moment, transaction support is only at the controller level.
>> >>>>> I.e. you
>> >>>>> can't make a service call transactional. Unless you call out to the
>> >>>>> DbContext method on a repository which I think is a leaky
>> >>>>> abstraction. Even
>> >>>>> at the controller level, you still need to manually rollback a
>> >>>>> database
>> >>>>> transaction if anything goes wrong.
>> >>>>> I like the idea of everything being transactional by default and
>> >>>>> maybe
>> >>>>> explicitly specifying when you *don't* want to use one.
>> >>>>> On Tue, Sep 22, 2009 at 7:38 AM, Tom Cabanski
>> >>>>> <t...@cabanski.com>wrote:
>> >>>>>> Isn't the Transaction attribute in SharpArch exactly what you are
>> >>>>>> talking about?
>> >>>>>> On Tue, Sep 22, 2009 at 6:04 AM, Vladan Strigo
>> >>>>>> <vla...@strigo.net>wrote:
>> >>>>>>> > I've been thinking about this for a while...in NH its
>> >>>>>>> > recommended
>> >>>>>>> to
>> >>>>>>> > put in transaction even the read operations. But to do something
>> >>>>>>> like:
>> >>>>>>> > sounds like alot of code which could be minimized...I've had an
>> >>>>>>> idea,
>> >>>>>>> > only didnt test till now that Session.Transaction.IsActive could
>> >>>>>>> > be
>> >>>>>>> > the key, and this morning read an article:
> > I've run across this exact same scenario and my solution was to use
> > the System.TransactionScope to wrap the database and email interaction
> > across one distributed transaction. I believe that
> > System.TransactionScope uses MSDTC under the hood, which coordinates
> > with database and non-database resources alike, such as an smtp
> > server.
> > I've pondered the idea of extending the [Transaction] attribute so
> > that it uses TransactionScope instead of just the NHibernate one. If
> > I'm not mistaken, an ADO.NET connection will automatically work within
> > the context of an MSDTC transaction...
> > On Sep 22, 8:47 am, Simone Busoli <simone.bus...@gmail.com> wrote:
> >> I don't see them as part of the business rules, but at times there's
> >> something that makes me think about transactions when I'm into the
> domain.
> >> Not everything you are doing might be transactional, think about email
> >> notifications.
> >> If you need to confirm a user about its registration, you might:
> >> - register the user, but fail to send the notification -> the
> transaction
> >> is
> >> rolled back and nothing happens
> >> - send the notification, but fail to save the user -> the transaction is
> >> rolled back but the email has already been sent
> >> I think an ideal way to manage these things is to have non transactional
> >> resources behave like transactional ones. In the example above
> >> - even if the notification fails, retry until it succeeds and therefore
> >> don't rollback the transaction
> >> - if the database save doesn't succeed, "undo" the send
> >> this can be accomplished in several ways, of which I don't know which
> are
> >> the best ones. Among them asynchronous messaging and out of process
> batch
> >> operations.
> >> On Tue, Sep 22, 2009 at 16:55, Kyle Baley <k...@baley.org> wrote:
> >> > That's a good point about it being at the boundaries. I can't think of
> >> > an
> >> > example of where I'd like to make the service call transactional but
> not
> >> > the
> >> > controller method.
> >> > Then again, are transactions typically part of the business rules?
> I.e.
> >> > If
> >> > we want three things saved in a transaction, should it be closer to
> the
> >> > domain?
> >> > On Tue, Sep 22, 2009 at 9:02 AM, Simone Busoli
> >> > <simone.bus...@gmail.com>wrote:
> >> >> The first part. BTW, transaction boundaries should be, well, at the
> >> >> boundaries, therefore on your controllers or web service endpoints.
> >> >> WRT everything transactional by default I don't think it should be a
> >> >> part
> >> >> of the project.
> >> >> On Tue, Sep 22, 2009 at 15:00, Kyle Baley <k...@baley.org> wrote:
> >> >>> Which part? Making the service call transactional or making
> everything
> >> >>> transactional by default? In either case, is this something that
> >> >>> should be
> >> >>> incorporated into S#arp?
> >> >>> On Tue, Sep 22, 2009 at 8:55 AM, Simone Busoli
> >> >>> <simone.bus...@gmail.com>wrote:
> >> >>>> Kyle, this is easilly accomplished with windsor and interceptors.
> >> >>>> On Tue, Sep 22, 2009 at 14:54, Kyle Baley <k...@baley.org> wrote:
> >> >>>>> The transaction support is something that I think needs some love.
> >> >>>>> At
> >> >>>>> the moment, transaction support is only at the controller level.
> >> >>>>> I.e. you
> >> >>>>> can't make a service call transactional. Unless you call out to
> the
> >> >>>>> DbContext method on a repository which I think is a leaky
> >> >>>>> abstraction. Even
> >> >>>>> at the controller level, you still need to manually rollback a
> >> >>>>> database
> >> >>>>> transaction if anything goes wrong.
> >> >>>>> I like the idea of everything being transactional by default and
> >> >>>>> maybe
> >> >>>>> explicitly specifying when you *don't* want to use one.
> >> >>>>> On Tue, Sep 22, 2009 at 7:38 AM, Tom Cabanski
> >> >>>>> <t...@cabanski.com>wrote:
> >> >>>>>> Isn't the Transaction attribute in SharpArch exactly what you are
> >> >>>>>> talking about?
> >> >>>>>> On Tue, Sep 22, 2009 at 6:04 AM, Vladan Strigo
> >> >>>>>> <vla...@strigo.net>wrote:
> >> >>>>>>> > I've been thinking about this for a while...in NH its
> >> >>>>>>> > recommended
> >> >>>>>>> to
> >> >>>>>>> > put in transaction even the read operations. But to do
> something
> >> >>>>>>> like:
> >> >>>>>>> > sounds like alot of code which could be minimized...I've had
> an
> >> >>>>>>> idea,
> >> >>>>>>> > only didnt test till now that Session.Transaction.IsActive
> could
> >> >>>>>>> > be
> >> >>>>>>> > the key, and this morning read an article:
