postInterceptor and transaction

[enji]

Hi,

I'm having trouble with transaction when I use postInterceptor.
Let's explain the problem in a simplified mode
I have an object Reference that can be linked to several ValidationTable objects (many-to-many association).
Both Reference and ValidationTable are involved in a publishing process.
When a Reference is published I need to validate that all its related ValidationTable are published too, and if not, I will publish first the ValidationTables and then my Reference.
My methods publishReference and publishValidationTable (both transactionnal) are intercepted with a postInterceptor and the corresponding advice (transactional too) generate an XML (switch to DOM4J session to generate the XML) for theses objects.

My problem is that the afterReturningAdvice close the transaction at the end of the method and as we publish objects in cascade and that for each publication AOP is thrown, after the first publication, the transaction is closed and we have an error that tell the transaction has not been successfully started.

org.springframework.transaction.TransactionSystemE xception: Could not roll back Hibernate transaction; nested exception is org.hibernate.TransactionException: Transaction not successfully started

AOP seems really appropriate to generate XML in post interception because this is a process we use almost everywhere in our application, but it seems that it does not allow cascading processes.
So the question is, is there a way to maintain the transaction opened when we use and afterReturningAdvice ?
Any idea would be helpful.

Thanks a lot

[denis.zhdanov]

It's not clear what do you mean under 'Reference is published'. Also it's not clear what is 'transactional advice' ('corresponding advice (transactional too) generate an XML').

[enji]

When we publish a Reference we change some of its properties (by example its status, set to 'published' and its published_version which is incremented)
Concerning the "transactional advice", this means that the advice needs to be executed within the transaction (because we interact with the DB)