Transactional static methods for Roo-generated Entity classes

[duckbill]

Hi,

Another issue I'm facing with Roo's rich Entity model:

How do I go about marking static methods transactional? I would like to be able to use the declarative way (i.e. @Transactional) instead of using, say, TransactionTemplate to drive transactions.

As an example, say I have an entity class called "Reservation" that carries an associated date. When the date has passed, I would like to remove the Reservation via a scheduled task that is run periodically. Hence what I would like to have is a static method Reservation.deletePastReservations(), that is executed via the Spring TaskExecutor abstraction, and run within a transaction.

Marking the static method with @Transactional does not do the trick. I can go around this by using an instance of the Reservation class and delegating to an instance method marked with @Transactional to do the work, but this looks like a hack, even though it is fairly concise. Can I somehow configure the aspectj TransactionAspect to include static methods?

I'm using maven 2.2 to build and it includes the aspectj plugin.

Any ideas? Or am I approaching the issue from an incorrect angle?

Thanks,
Jukka

[Stefan Schmidt]

Hi Jukka,

As you have seen Spring Roo makes use of standard Spring framework features including the Spring transaction model. The Spring transaction module is driven by AspectJ which does currently not support the use of the @Transactional annotation on static methods. Since Roo has no intention to enforce runtime dependencies which would need to be implemented to overcome this problem I would like to refer you to the Spring framework Jira and open a feature improvement ticket requesting the support of @transactional annotations via it's AspectJ integration.

To solve your immediate problem it would probably be best if you create a separate service layer object (or a simple Pojo) which takes care of deleting reservations. This way you would also preserve coherence for your actual entity.

Hope this helps.

-Stefan

[duckbill]

Hi Stefan,

Thanks for your reply.

To solve your immediate problem it would probably be best if you create a separate service layer object (or a simple Pojo) which takes care of deleting reservations. This way you would also preserve coherence for your actual entity.

That's true, got so carried away with all the new stuff that I forgot to utilize the usual layered design. A simple service bean would indeed do the work nicely, and would fit in to the TaskExecutor abstraction as well.

On the other hand, @Transactional static methods may just come in handy at some point, so I filed the request to Spring Jira http://jira.springframework.org/browse/SPR-5999.

Thanks again,
Jukka