Quantcast

Rolling back transactions on checked exceptions

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Rolling back transactions on checked exceptions

Jeff Storey

It seems like you would typically want to rollback transactions when a checked exception occurs (that is not caught and handled in your code) since groovy does not force you to catch the checked exceptions, and that can lead to some unexpected transaction behavior. I saw the grails transaction handling plugin to allow this behavior http://grails.org/plugin/transaction-handling, but I’m wondering if this is a standard thing to do in grails. Or is there a better way to approach this problem? I can’t see a reason why you wouldn’t want to rollback the transaction if an uncaught exception occurs (checked or unchecked).

 

Thanks,

Jeff

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rolling back transactions on checked exceptions

alxndrsn
On 8 September 2012 20:14, Jeff Storey <[hidden email]> wrote:
> It seems like you would typically want to rollback transactions when a
> checked exception occurs (that is not caught and handled in your code) since
> groovy does not force you to catch the checked exceptions, and that can lead
> to some unexpected transaction behavior. I saw the grails transaction
> handling plugin to allow this behavior
> http://grails.org/plugin/transaction-handling, but I’m wondering if this is
> a standard thing to do in grails. Or is there a better way to approach this
> problem? I can’t see a reason why you wouldn’t want to rollback the
> transaction if an uncaught exception occurs (checked or unchecked).

Just trying to understand this: by "checked" exception, do you mean
any non-runtime exception?  Or one that is explicitly declared?

Would the following fail to roll back the transaction:

    def serviceMethod() {
        ...
        throw new Exception()
        ...
    }

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rolling back transactions on checked exceptions

ideasculptor


On Tue, Sep 18, 2012 at 9:42 PM, Alex Anderson <[hidden email]> wrote:
On 8 September 2012 20:14, Jeff Storey <[hidden email]> wrote:
> It seems like you would typically want to rollback transactions when a
> checked exception occurs (that is not caught and handled in your code) since
> groovy does not force you to catch the checked exceptions, and that can lead
> to some unexpected transaction behavior. I saw the grails transaction
> handling plugin to allow this behavior
> http://grails.org/plugin/transaction-handling, but I’m wondering if this is
> a standard thing to do in grails. Or is there a better way to approach this
> problem? I can’t see a reason why you wouldn’t want to rollback the
> transaction if an uncaught exception occurs (checked or unchecked).

Just trying to understand this: by "checked" exception, do you mean
any non-runtime exception?  Or one that is explicitly declared?

Would the following fail to roll back the transaction:

    def serviceMethod() {
        ...
        throw new Exception()
        ...
    }


The default behavior in Spring's transaction handling has always been to rollback for unchecked exceptions but commit in the presence of checked exceptions.  But Spring's jdbc/orm wrappers also convert all checked exceptions thrown by the various frameworks/layers into a consistent set of unchecked exceptions that are framework-independent.  The thinking is that any checked exceptions will therefore be checked exceptions thrown by YOUR code not a lower framework layer, and that you will use checked exceptions explicitly for error conditions which are continuable, while runtime exceptions are generally unrecoverable abort conditions.   Any calls to the java api (or others) you make directly will necessarily (in Java) require you to catch and rethrow unchecked or otherwise explicitly handle the exception, so you can also dictate the strategy the transaction interceptor uses for dealing with those exceptions you choose to declare instead of catch, via the @Transactional annotation or the transaction interceptor bean declaration.  This falls over a little in groovy, since the compiler doesn't force you to catch or declare any checked exceptions, but preserving the ability for some exceptions to occur without aborting the current transaction is still incredibly useful. It should be possible to change the behaviour of the transaction handling in grails to rollback on all exceptions or just on an explicitly listed set of subclasses of exception, if you are so inclined.  Or you can code to the same convention and use checked exceptions for error conditions that are continuable and unchecked exceptions when you need to rollback.  Just because groovy doesn't force you to handle checked exceptions doesn't mean that your application shouldn't still deal with them in an appropriate manner.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rolling back transactions on checked exceptions

pledbrook
In reply to this post by Jeff Storey
> It seems like you would typically want to rollback transactions when a
> checked exception occurs (that is not caught and handled in your code) since
> groovy does not force you to catch the checked exceptions, and that can lead
> to some unexpected transaction behavior. I saw the grails transaction
> handling plugin to allow this behavior
> http://grails.org/plugin/transaction-handling, but I’m wondering if this is
> a standard thing to do in grails. Or is there a better way to approach this
> problem? I can’t see a reason why you wouldn’t want to rollback the
> transaction if an uncaught exception occurs (checked or unchecked).

I believe the default should be changed to roll back on *all*
exceptions specifically because Groovy treats all exceptions as
runtime ones (but Spring doesn't). Unfortunately this simply hasn't
been on the radar with other work that's being done.

Contributions welcome!

Peter

--
Peter Ledbrook
Developer Advocate
VMware

t: @pledbrook

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rolling back transactions on checked exceptions

alxndrsn
On 19 September 2012 12:45, Peter Ledbrook <[hidden email]> wrote:

>> It seems like you would typically want to rollback transactions when a
>> checked exception occurs (that is not caught and handled in your code) since
>> groovy does not force you to catch the checked exceptions, and that can lead
>> to some unexpected transaction behavior. I saw the grails transaction
>> handling plugin to allow this behavior
>> http://grails.org/plugin/transaction-handling, but I’m wondering if this is
>> a standard thing to do in grails. Or is there a better way to approach this
>> problem? I can’t see a reason why you wouldn’t want to rollback the
>> transaction if an uncaught exception occurs (checked or unchecked).
>
> I believe the default should be changed to roll back on *all*
> exceptions specifically because Groovy treats all exceptions as
> runtime ones (but Spring doesn't). Unfortunately this simply hasn't
> been on the radar with other work that's being done.

Samuel, thanks for the clear explanation of the current behaviour.
I'd still argue it's not obvious or expected behaviour, and a more
friendly implementation would:
1. roll back on ANY exception
2. allow for a method-level annotation to indicate that certain
exceptions are not rolled back, e.g.

    @NoRollbackWith(MyExceptionWhichMightOrMightNotBeARuntimeException.class)

Peter, is there a JIRA for this?

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rolling back transactions on checked exceptions

pledbrook
> Peter, is there a JIRA for this?

I can't find one.

--
Peter Ledbrook
Developer Advocate
VMware

t: @pledbrook

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rolling back transactions on checked exceptions

Graeme Rocher
Administrator
This plugin may be relevant to the the discussion:

https://github.com/mbezjak/rollback-on-exception

It changes the default to rollback checked exceptions as well

Cheers

On Wed, Sep 19, 2012 at 12:08 PM, Peter Ledbrook <[hidden email]> wrote:

>> Peter, is there a JIRA for this?
>
> I can't find one.
>
> --
> Peter Ledbrook
> Developer Advocate
> VMware
>
> t: @pledbrook
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>



--
Graeme Rocher
Grails Project Lead
SpringSource - A Division of VMware
http://www.springsource.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rolling back transactions on checked exceptions

ideasculptor
In reply to this post by alxndrsn


On Wed, Sep 19, 2012 at 2:52 AM, Alex Anderson <[hidden email]> wrote:
On 19 September 2012 12:45, Peter Ledbrook <[hidden email]> wrote:
>
> I believe the default should be changed to roll back on *all*
> exceptions specifically because Groovy treats all exceptions as
> runtime ones (but Spring doesn't). Unfortunately this simply hasn't
> been on the radar with other work that's being done.

That would be a HUGE breaking change.  The default should be left alone. But the framework could certainly make it easier to change the behaviour globally and document how that is done.
 

Samuel, thanks for the clear explanation of the current behaviour.
I'd still argue it's not obvious or expected behaviour, and a more
friendly implementation would:
1. roll back on ANY exception
2. allow for a method-level annotation to indicate that certain
exceptions are not rolled back, e.g.

    @NoRollbackWith(MyExceptionWhichMightOrMightNotBeARuntimeException.class)

Peter, is there a JIRA for this?

Spring's @Transactional annotation works just fine in grails and has attributes that let you specify exactly what exceptions will and will not be rolled back.  It can be applied on a per-class basis (in lieu of the static transactional definition in grails services) or on a per-method basis, or both, with the method annotation overriding the class annotation.  I don't know if there's a way to specify rollbackFor and noRollbackFor with the static transactional declaration in grails services.  My guess is you have to use the annotation for that kind of control.

Spring's documentation coves the annotation's use in detail, but the javadoc is here: http://static.springsource.org/spring/docs/3.0.x/javadoc-api/org/springframework/transaction/annotation/Transactional.html


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rolling back transactions on checked exceptions

Miro Bezjak
I have to disagree. In my opinion, rollback for any throwable is a better default then the current one (rollback for java.lang.Error and java.lang.RuntimeException). I think that it is reasonable to expect transaction rollback in the event of unforeseen circumstance or when you can't implement reasonable exception handling logic in a service method (e.g. for some situations involving java.sql.SQLException, java.io.IOException, etc.). Spring's defaults aren't necessarily best for Grails as well. Particularly because Groovy doesn't distinguish checked and unchecked exceptions.

Spring's @Transactional annotation works but, in my opinion, it has a (fatal?) flaw. You need to remember to use it. If you forget and ship code to production, it could lead to errors that are really hard to track down.

Cheers,
Miro


On Fri, Sep 21, 2012 at 11:12 AM, Samuel Gendler <[hidden email]> wrote:


On Wed, Sep 19, 2012 at 2:52 AM, Alex Anderson <[hidden email]> wrote:
On 19 September 2012 12:45, Peter Ledbrook <[hidden email]> wrote:
>
> I believe the default should be changed to roll back on *all*
> exceptions specifically because Groovy treats all exceptions as
> runtime ones (but Spring doesn't). Unfortunately this simply hasn't
> been on the radar with other work that's being done.

That would be a HUGE breaking change.  The default should be left alone. But the framework could certainly make it easier to change the behaviour globally and document how that is done.
 

Samuel, thanks for the clear explanation of the current behaviour.
I'd still argue it's not obvious or expected behaviour, and a more
friendly implementation would:
1. roll back on ANY exception
2. allow for a method-level annotation to indicate that certain
exceptions are not rolled back, e.g.

    @NoRollbackWith(MyExceptionWhichMightOrMightNotBeARuntimeException.class)


Peter, is there a JIRA for this?

Spring's @Transactional annotation works just fine in grails and has attributes that let you specify exactly what exceptions will and will not be rolled back.  It can be applied on a per-class basis (in lieu of the static transactional definition in grails services) or on a per-method basis, or both, with the method annotation overriding the class annotation.  I don't know if there's a way to specify rollbackFor and noRollbackFor with the static transactional declaration in grails services.  My guess is you have to use the annotation for that kind of control.

Spring's documentation coves the annotation's use in detail, but the javadoc is here: http://static.springsource.org/spring/docs/3.0.x/javadoc-api/org/springframework/transaction/annotation/Transactional.html



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rolling back transactions on checked exceptions

pledbrook
In reply to this post by ideasculptor
>> On 19 September 2012 12:45, Peter Ledbrook <[hidden email]> wrote:
>> >
>> > I believe the default should be changed to roll back on *all*
>> > exceptions specifically because Groovy treats all exceptions as
>> > runtime ones (but Spring doesn't). Unfortunately this simply hasn't
>> > been on the radar with other work that's being done.
>
>
> That would be a HUGE breaking change.  The default should be left alone. But
> the framework could certainly make it easier to change the behaviour
> globally and document how that is done.

Is it really such a huge change? Is code going to be reliant on
checked exceptions (in Groovy services remember!) not rolling back the
transaction? Possibly. Intentionally relying on that fact? Probably
not. Should we keep a default that affects all new users (and existing
users like me) in order not to break applications that rely on the
existing behaviour?

I don't profess to know the answer. I know that breaking changes
should not be undertaken lightly. It might make better sense to
install the rollback-on-exception plugin by default for new projects.
But I do think we need to acknowledge this as a long standing problem
that has had many people scratching their heads at one time or
another.

Peter

--
Peter Ledbrook
Developer Advocate
VMware

t: @pledbrook

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rolling back transactions on checked exceptions

ideasculptor


On Fri, Sep 21, 2012 at 4:08 AM, Peter Ledbrook <[hidden email]> wrote:
>> On 19 September 2012 12:45, Peter Ledbrook <[hidden email]> wrote:
>> >
>> > I believe the default should be changed to roll back on *all*
>> > exceptions specifically because Groovy treats all exceptions as
>> > runtime ones (but Spring doesn't). Unfortunately this simply hasn't
>> > been on the radar with other work that's being done.
>
>
> That would be a HUGE breaking change.  The default should be left alone. But
> the framework could certainly make it easier to change the behaviour
> globally and document how that is done.

Is it really such a huge change? Is code going to be reliant on
checked exceptions (in Groovy services remember!) not rolling back the
transaction? Possibly. Intentionally relying on that fact? Probably
not. Should we keep a default that affects all new users (and existing
users like me) in order not to break applications that rely on the
existing behaviour?

Anyone who has read the docs and relies upon the fact that checked exceptions don't roll back will find their app behaviour utterly changed as a result of a framework upgrade if the behaviour changes.  Maybe add a new value to Config.groovy for new apps which modifies the behaviour to what you desire, but the default behaviour if nothing is specified in the config should remain unchanged to avoid potentially breaking lots of existing applications.

 

I don't profess to know the answer. I know that breaking changes
should not be undertaken lightly. It might make better sense to
install the rollback-on-exception plugin by default for new projects.
But I do think we need to acknowledge this as a long standing problem
that has had many people scratching their heads at one time or
another.


If the problem is head scratching, much of that could be ameliorated by simply making a big deal about it in the documentation and tutorials so tha it doesn't go unnoticed.  It's perfectly reasonable to modify grails so that new apps are generated with a config that sets checked exceptions to roll back, but there's no good reason to force that behaviour on existing apps in an upgrade when the config option is an available solution, IMO.

 
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rolling back transactions on checked exceptions

burtbeckwith
Agreed - it would be simple to use a config option to change the automatic transaction behavior added to services (defaulting to the current semantics), and if you use @Transactional then you can do whatever you need.

I sympathize with users who have gotten burned by this and other surprising behaviors, but I'm reluctant to break Grails to make it safer to use when you don't know much (yet) about how things work (the same goes for the recent failOnError discussion).

Burt

ideasculptor wrote
On Fri, Sep 21, 2012 at 4:08 AM, Peter Ledbrook <[hidden email]>wrote:

> >> On 19 September 2012 12:45, Peter Ledbrook <[hidden email]>
> wrote:
> >> >
> >> > I believe the default should be changed to roll back on *all*
> >> > exceptions specifically because Groovy treats all exceptions as
> >> > runtime ones (but Spring doesn't). Unfortunately this simply hasn't
> >> > been on the radar with other work that's being done.
> >
> >
> > That would be a HUGE breaking change.  The default should be left alone.
> But
> > the framework could certainly make it easier to change the behaviour
> > globally and document how that is done.
>
> Is it really such a huge change? Is code going to be reliant on
> checked exceptions (in Groovy services remember!) not rolling back the
> transaction? Possibly. Intentionally relying on that fact? Probably
> not. Should we keep a default that affects all new users (and existing
> users like me) in order not to break applications that rely on the
> existing behaviour?
>

Anyone who has read the docs and relies upon the fact that checked
exceptions don't roll back will find their app behaviour utterly changed as
a result of a framework upgrade if the behaviour changes.  Maybe add a new
value to Config.groovy for new apps which modifies the behaviour to what
you desire, but the default behaviour if nothing is specified in the config
should remain unchanged to avoid potentially breaking lots of existing
applications.



>
> I don't profess to know the answer. I know that breaking changes
> should not be undertaken lightly. It might make better sense to
> install the rollback-on-exception plugin by default for new projects.
> But I do think we need to acknowledge this as a long standing problem
> that has had many people scratching their heads at one time or
> another.
>
>
If the problem is head scratching, much of that could be ameliorated by
simply making a big deal about it in the documentation and tutorials so tha
it doesn't go unnoticed.  It's perfectly reasonable to modify grails so
that new apps are generated with a config that sets checked exceptions to
roll back, but there's no good reason to force that behaviour on existing
apps in an upgrade when the config option is an available solution, IMO.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rolling back transactions on checked exceptions

alxndrsn
In reply to this post by ideasculptor
> It's perfectly reasonable to modify grails so that
> new apps are generated with a config that sets checked exceptions to roll
> back, but there's no good reason to force that behaviour on existing apps in
> an upgrade when the config option is an available solution, IMO.

This sounds a very good balance to me.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rolling back transactions on checked exceptions

eeno
In reply to this post by burtbeckwith
On Fri, Sep 21, 2012 at 09:51:59AM -0700, burtbeckwith wrote:
> Agreed - it would be simple to use a config option to change the automatic
> transaction behavior added to services (defaulting to the current
> semantics), and if you use @Transactional then you can do whatever you need.
>

Another additional strategy - modify the default Service scaffolding
shipped with grails to define a:

@Transactional(rollbackFor = Throwable)

... at the class level of all generated Services.

Then with clear documentation in the official grails user guide to
illuminate and clarify the purpose of this change. The info provided
in the rollback-on-exception plugin does a rather excellent job
explaining things and could be used as inspiration for the official
grails docs:

https://github.com/mbezjak/rollback-on-exception/blob/master/README.md




---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rolling back transactions on checked exceptions

pledbrook
In reply to this post by burtbeckwith
> Agreed - it would be simple to use a config option to change the automatic
> transaction behavior added to services (defaulting to the current
> semantics), and if you use @Transactional then you can do whatever you need.
>
> I sympathize with users who have gotten burned by this and other surprising
> behaviors, but I'm reluctant to break Grails to make it safer to use when
> you don't know much (yet) about how things work (the same goes for the
> recent failOnError discussion).

Another factor in both those discussions and the one on codecs is the
plugin system. As we know from the default codec setting, adding a
config option to change the behaviour can easily break existing
plugins.

That doesn't mean we shouldn't implement it, but careful thought needs
to be applied to how plugins handle the new options. They could just
check the global config object, but a) they may not have ready access
to it, and b) this is a higher burden of maintenance than having a
simple API for them to query.

Peter

--
Peter Ledbrook
Developer Advocate
VMware

t: @pledbrook

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rolling back transactions on checked exceptions

pledbrook
In reply to this post by eeno
> Another additional strategy - modify the default Service scaffolding
> shipped with grails to define a:
>
> @Transactional(rollbackFor = Throwable)

Although an option, I think this approach moves Grails from being a
convention-over-configuration framework to an annotation-driven one. I
think annotations are a useful addition, but they should not be the
first port of call.

Just my 2p

Peter

--
Peter Ledbrook
Developer Advocate
VMware

t: @pledbrook

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rolling back transactions on checked exceptions

ideasculptor


On Mon, Sep 24, 2012 at 6:15 AM, Peter Ledbrook <[hidden email]> wrote:
> Another additional strategy - modify the default Service scaffolding
> shipped with grails to define a:
>
> @Transactional(rollbackFor = Throwable)

Although an option, I think this approach moves Grails from being a
convention-over-configuration framework to an annotation-driven one. I
think annotations are a useful addition, but they should not be the
first port of call.

Just my 2p

Yes, I agree with you there.  An annotation for core functionality isn't very grails-y.

One consideration might be adding the ability to specify more options in the static transactional definition in a service class.  Allow transactional to be assigned a map instead of a boolean, if desired.

static def transactional = [
    enabled : true,
    rollbackFor: [Throwable],
    noRollbackFor: [MySpecialCaseException],
    isolation: SERIALIZABLE,
    propagation: REQUIRES_NEW,
    timeout: 10000,
    readOnly: false
]

At the moment, one has to switch to annotations to specify any details about transactional behaviour that are different from the defaults. This would correct that, while still allowing a developer to use the simpler form of:

static def transactional = true

since I assume it would be a relatively small matter to check the type of the transactional member when setting up the proxy for the service class.

 

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rolling back transactions on checked exceptions

Bob Brown
I like the idea of a transactional = [] block or transactional = {}
closure...seems to me that it is more in keeping with the rest of Grails.

But: what about per-method behavior...for example:

--- from:
http://static.springsource.org/spring/docs/2.0.x/reference/transaction.html
---
@Transactional(readOnly = true)
public class DefaultFooService implements FooService {

    public Foo getFoo(String fooName) {
        // do something
    }

    // these settings have precedence for this method
    @Transactional(readOnly = false, propagation = Propagation.REQUIRES_NEW)
    public void updateFoo(Foo foo) {
        // do something
    }
}
---

Would it not quite quickly get a bit large/messy?

static def transactional = [
   class: [
     enabled : true,
     rollbackFor: [Throwable],
     noRollbackFor: [MySpecialCaseException],
     isolation: SERIALIZABLE,
     propagation: PROPAGATION_REQUIRED,
     timeout: 10000,
     readOnly: false],
  updateFoo: [
    enabled: true,
    propagation: REQURES_NEW,
    readOnly: true
  ]
]

Is there any cleaner way? Sensible defaults would cut the amount of 'stuff'
down, of course...

I am wondering if--after all that work--annotations might just be
preferable?

Cheers,

BOB
> -----Original Message-----
> From: Samuel Gendler [mailto:[hidden email]]
> Sent: Tuesday, 25 September 2012 5:29 AM
> To: [hidden email]
> Subject: Re: [grails-user] Re: Rolling back transactions on checked
exceptions
>
>
>
> On Mon, Sep 24, 2012 at 6:15 AM, Peter Ledbrook <[hidden email]>
> wrote:
>
>
> > Another additional strategy - modify the default Service
scaffolding

> > shipped with grails to define a:
> >
> > @Transactional(rollbackFor = Throwable)
>
>
> Although an option, I think this approach moves Grails from being a
> convention-over-configuration framework to an annotation-driven
> one. I
> think annotations are a useful addition, but they should not be the
> first port of call.
>
> Just my 2p
>
>
>
> Yes, I agree with you there.  An annotation for core functionality isn't
very
> grails-y.
>
> One consideration might be adding the ability to specify more options in
the
> static transactional definition in a service class.  Allow transactional
to be

> assigned a map instead of a boolean, if desired.
>
> static def transactional = [
>     enabled : true,
>     rollbackFor: [Throwable],
>     noRollbackFor: [MySpecialCaseException],
>     isolation: SERIALIZABLE,
>     propagation: REQUIRES_NEW,
>     timeout: 10000,
>     readOnly: false
> ]
>
> At the moment, one has to switch to annotations to specify any details
about
> transactional behaviour that are different from the defaults. This would
> correct that, while still allowing a developer to use the simpler form of:
>
> static def transactional = true
>
> since I assume it would be a relatively small matter to check the type of
the
> transactional member when setting up the proxy for the service class.
>
>



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rolling back transactions on checked exceptions

ideasculptor
Yeah, I was thinking about the map/closure for the static transactional member purely in the case where you are still applying a single setting to the service.  It's too mess and too divorced from the actual method declarations to do per-method overrides in a single location like that.  If you need per-method overrides, falling back to the annotation still makes sense.  My suggestion just gives a little more control over the current default transaction semantics.  I considered suggesting a list of methods in that map, for local overrides, but rejected it for not being grails-y.  The annotation solves that problem in a better way.  What might be nice would be the ability to use the static member for service defaults, but annotations just for override.  At the moment, any single annotation causes the static member to be ignored, meaning that you must annotate the class to provide defaults and then use overrides on individual methods.  There's not much difference between that and retaining the static member, but keeping the static member prevents unexpected side effects - I can see where a user might add an annotation to a single method as an override, without realizing that they just disabled transactionality on every other method in the class.  It'd be good to avoid that.



On Tue, Sep 25, 2012 at 4:21 PM, Bob Brown <[hidden email]> wrote:
I like the idea of a transactional = [] block or transactional = {}
closure...seems to me that it is more in keeping with the rest of Grails.

But: what about per-method behavior...for example:

--- from:
http://static.springsource.org/spring/docs/2.0.x/reference/transaction.html
---
@Transactional(readOnly = true)
public class DefaultFooService implements FooService {

    public Foo getFoo(String fooName) {
        // do something
    }

    // these settings have precedence for this method
    @Transactional(readOnly = false, propagation = Propagation.REQUIRES_NEW)
    public void updateFoo(Foo foo) {
        // do something
    }
}
---

Would it not quite quickly get a bit large/messy?

static def transactional = [
   class: [
     enabled : true,
     rollbackFor: [Throwable],
     noRollbackFor: [MySpecialCaseException],
     isolation: SERIALIZABLE,
     propagation: PROPAGATION_REQUIRED,
     timeout: 10000,
     readOnly: false],
  updateFoo: [
    enabled: true,
    propagation: REQURES_NEW,
    readOnly: true
  ]
]

Is there any cleaner way? Sensible defaults would cut the amount of 'stuff'
down, of course...

I am wondering if--after all that work--annotations might just be
preferable?

Cheers,

BOB
> -----Original Message-----
> From: Samuel Gendler [mailto:[hidden email]]
> Sent: Tuesday, 25 September 2012 5:29 AM
> To: [hidden email]
> Subject: Re: [grails-user] Re: Rolling back transactions on checked
exceptions
>
>
>
> On Mon, Sep 24, 2012 at 6:15 AM, Peter Ledbrook <[hidden email]>
> wrote:
>
>
>       > Another additional strategy - modify the default Service
scaffolding
>       > shipped with grails to define a:
>       >
>       > @Transactional(rollbackFor = Throwable)
>
>
>       Although an option, I think this approach moves Grails from being a
>       convention-over-configuration framework to an annotation-driven
> one. I
>       think annotations are a useful addition, but they should not be the
>       first port of call.
>
>       Just my 2p
>
>
>
> Yes, I agree with you there.  An annotation for core functionality isn't
very
> grails-y.
>
> One consideration might be adding the ability to specify more options in
the
> static transactional definition in a service class.  Allow transactional
to be
> assigned a map instead of a boolean, if desired.
>
> static def transactional = [
>     enabled : true,
>     rollbackFor: [Throwable],
>     noRollbackFor: [MySpecialCaseException],
>     isolation: SERIALIZABLE,
>     propagation: REQUIRES_NEW,
>     timeout: 10000,
>     readOnly: false
> ]
>
> At the moment, one has to switch to annotations to specify any details
about
> transactional behaviour that are different from the defaults. This would
> correct that, while still allowing a developer to use the simpler form of:
>
> static def transactional = true
>
> since I assume it would be a relatively small matter to check the type of
the
> transactional member when setting up the proxy for the service class.
>
>



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



Loading...