Automated transaction handling

[Jochen Wiedmann <jo...@gmail.com>]

Hi,

I would like, whether and how it is possible to automate a controllers
transaction handling. I am thinking around the following lines:

- I register a listener that is invoked before the action and after the action.
- The listener starts the transaction in the first invocation. In the
second invocation, the
  listener commits the transaction, if no exception was raised.
Otherwise, the listener
  performs a rollback.

IMO, such handling would be very convenient to ensure a common and
safe exception handling. It would also provide a common place for
exception logging.

Thanks,

Jochen

-- 
How fast can a year go? As fast as your childs first year.

Re: Automated transaction handling

[Werner Punz <we...@gmail.com>]

Werner Punz schrieb:

>> IMO, such handling would be very convenient to ensure a common and
>> safe exception handling. It would also provide a common place for
>> exception logging.

Ok another pattern, to solve this problem in an automated way.
Use Spring use automated transactions, and also use AOP.
You define beans with business methods under transactional scope
you execute them
the commit rollback is done automated.
in case of an exception add an AOP Layer around those beans
with an interceptor who does the logging.

on the ui layer add a navigation handler to the mix, which pushes in
case of the exception the user into an error page.

This should resolve most use cases without mixing the layers.

You probably get similar results in EJB3 on an app server which supports
AOP.

but things like controlled exception handling recovery/logging with
automated mechanisms probably is really a classical domain for aspect
oriented programming.

I highly recommend to take a short time of reading into the Spring
framework to get more insight and new tools for such usecases.

Re: Automated transaction handling

[Craig McClanahan <cr...@apache.org>]

On 2/7/07, Werner Punz <we...@gmail.com> wrote:
>
> Jochen Wiedmann schrieb:
> > On 2/7/07, Werner Punz <we...@gmail.com> wrote:
> >
> >> Right idea wrong tier of the application stack, automated transaction
> >> handling is in the realm
> >> of the middleware, I highly can recommend to have a look at EJB3 and/or
> >> Spring maybe even Seam.
> >> Thing is automated transaction handling is already covered
> >> by apis like Java Transaction API, the @Transactional annotation
> >> of Spring or EJB
> >> and or various other constructs in Spring or EJB.
> >> JSF itself is mainly the view layer.
> >
> > I must admit, that I have no idea about Spring. However, the Java
> > Transaction API, and/or EJB do clearly not cover these topics. I
> > wouldn't want to like to discuss this in detail, but I know of no
> > application where I didn't require a UserTransaction sooner or later.
> > And then I am back to my original question: How do I control it
> > automatically?
> >
>
>
>
> ok if you want to bypass the app servers transaction mechanisms, then
> you have various options:
>
> First of all, you have to implement the rollback/commit and
> opentransaction parts yourself in most cases.
> Secondly there are various hook points to add it, if you want to have it
> semi generic in the view layer such as:
>
> a) Write your own view handler which roots basically into the original
> one, but deals with the transactions
>
> b) use a generic opensessionin view filter or something similar which
> hooks into the servlet api
>
> c) write your own servlet filter to deal with it
>
> d) Use the shale view controller which has clear callback points which
> are always called and add your transaction code there
>
> One option is out of question, if you want to use phase listeners for
> it, forget it, phase listeners can be called but mustn't.
>
> The others is up to your choice.


If you really do want to do something like this as you originally proposed
(by wrapping the call to the action method somehow), you can actually do
that as well.  A JSF implementation provides a default ActionListener whose
basic purpose is to  evaluate the value of the "action" property, treat a
literal string as an outcome or call through via a method binding, and then
do the navigation.  You can register your own replacement for this listener
in faces-config.xml like this:

<faces-config>
    <application>
        <action-listener>FQCN of my action listener class</action-listener>
    </application>
</faces-config>

You'll probably want to delegate to the standard registered listener to do
the action call and navigation stuff, wrapping this in whatever you want to
do for exception handling.

The Shale ViewController[1] package has an example of this[2] that
implements its own exception handling strategy, to give you an idea of how
you might roll your own.

Craig

[1] http://shale.apache.org/shale-view/
[2]
http://svn.apache.org/viewvc/shale/framework/trunk/shale-view/src/main/java/org/apache/shale/view/faces/ViewActionListener.java?view=co

Re: Automated transaction handling

[Werner Punz <we...@gmail.com>]

Jochen Wiedmann schrieb:
> On 2/7/07, Werner Punz <we...@gmail.com> wrote:
> 
>> Right idea wrong tier of the application stack, automated transaction
>> handling is in the realm
>> of the middleware, I highly can recommend to have a look at EJB3 and/or
>> Spring maybe even Seam.
>> Thing is automated transaction handling is already covered
>> by apis like Java Transaction API, the @Transactional annotation
>> of Spring or EJB
>> and or various other constructs in Spring or EJB.
>> JSF itself is mainly the view layer.
> 
> I must admit, that I have no idea about Spring. However, the Java
> Transaction API, and/or EJB do clearly not cover these topics. I
> wouldn't want to like to discuss this in detail, but I know of no
> application where I didn't require a UserTransaction sooner or later.
> And then I am back to my original question: How do I control it
> automatically?
> 



ok if you want to bypass the app servers transaction mechanisms, then
you have various options:

First of all, you have to implement the rollback/commit and
opentransaction parts yourself in most cases.
Secondly there are various hook points to add it, if you want to have it
semi generic in the view layer such as:

a) Write your own view handler which roots basically into the original
one, but deals with the transactions

b) use a generic opensessionin view filter or something similar which
hooks into the servlet api

c) write your own servlet filter to deal with it

d) Use the shale view controller which has clear callback points which
are always called and add your transaction code there

One option is out of question, if you want to use phase listeners for
it, forget it, phase listeners can be called but mustn't.

The others is up to your choice.

Re: Automated transaction handling

[Jochen Wiedmann <jo...@gmail.com>]

On 2/7/07, Werner Punz <we...@gmail.com> wrote:

> Right idea wrong tier of the application stack, automated transaction
> handling is in the realm
> of the middleware, I highly can recommend to have a look at EJB3 and/or
> Spring maybe even Seam.
> Thing is automated transaction handling is already covered
> by apis like Java Transaction API, the @Transactional annotation
> of Spring or EJB
> and or various other constructs in Spring or EJB.
> JSF itself is mainly the view layer.

I must admit, that I have no idea about Spring. However, the Java
Transaction API, and/or EJB do clearly not cover these topics. I
wouldn't want to like to discuss this in detail, but I know of no
application where I didn't require a UserTransaction sooner or later.
And then I am back to my original question: How do I control it
automatically?

Jochen

-- 
How fast can a year go? As fast as your childs first year.

Re: Automated transaction handling

[Werner Punz <we...@gmail.com>]

Jochen Wiedmann schrieb:
> Hi,
> 
> I would like, whether and how it is possible to automate a controllers
> transaction handling. I am thinking around the following lines:
> 
> - I register a listener that is invoked before the action and after the
> action.
> - The listener starts the transaction in the first invocation. In the
> second invocation, the
>  listener commits the transaction, if no exception was raised.
> Otherwise, the listener
>  performs a rollback.
> 
> IMO, such handling would be very convenient to ensure a common and
> safe exception handling. It would also provide a common place for
> exception logging.
> 
Right idea wrong tier of the application stack, automated transaction
handling is in the realm
of the middleware, I highly can recommend to have a look at EJB3 and/or
Spring maybe even Seam.
Thing is automated transaction handling is already covered
by apis like Java Transaction API, the @Transactional annotation
of Spring or EJB
and or various other constructs in Spring or EJB.
JSF itself is mainly the view layer.