This week's book giveaway is in the Java 8 forum.
We're giving away four copies of Java 8 in Action and have Raoul-Gabriel Urma, Mario Fusco, and Alan Mycroft on-line!
See this thread for details.
The moose likes EJB and other Java EE Technologies and the fly likes NotSupported TransactionAttribute Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Java 8 in Action this week in the Java 8 forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "NotSupported TransactionAttribute" Watch "NotSupported TransactionAttribute" New topic
Author

NotSupported TransactionAttribute

Sudarshan Sreenivasan
Ranch Hand

Joined: Jun 28, 2007
Posts: 188

Hi
I am using OC4j standard edition and EJB2.1, the problem is as follows

method1(Requires Transaction attribute)
{
update 1
calls method 2
}

method2(NotSupported Transaction attribute)
{
update 2 (This update should be temporary)
select based on update from method 2
}


Expected Result : Update 2 should be rollbacked after the select has been performed.As it runs in a "unspecified transaction context"

Actual Result : Update 2 is being committed.

After a bit of reading i get that "unspecified transaction context" could be implemented anyhow by the container provider !!

I had earlier used this approach

method2(RequiredNew Transaction attribute)
{
update 2 (This update should be temporary)
select based on update from method 2
setSessionRollbackOnly()
}

However this gave me a exception (dont quite remember the exception though)


Any one knows of a URL where i find how oc4j actually implements "unspecified transaction context" ???

Any suggestions on how i could get this working ???
Ahmed Basheer
Ranch Hand

Joined: Apr 15, 2004
Posts: 77
I have a quick suggestion for you to try it. Can you call method 2 from method1 not directly but by using the container API. If you call method 2 directly from method 1, then method 2 also runs in the same transaction as method 1 and method 2 transactions attributes don't matter.
Sudarshan Sreenivasan
Ranch Hand

Joined: Jun 28, 2007
Posts: 188


Can you call method 2 from method1 not directly but by using the container API.

how does one do that , an example would help


If you call method 2 directly from method 1, then method 2 also runs in the same transaction as method 1 and method 2 transactions attributes don't matter


Do not agree with this , the transaction attributes can be specified on a per method basis , in my example above method 1 and method 2 will run with different transaction attributes.

Transaction attributes are specified in ejb-jar.xml.




method2(RequiredNew Transaction attribute)
{
update 2 (This update should be temporary)
select based on update from method 2
setSessionRollbackOnly()

select query here
}


with reference to my earlier post.

The exception was raised on the select query after having marked the session for a rollback.

This happened irrespective of the transaction attribute given to method2.

This happens on for oc4j standard edition (Works with enterprise edition and standalone editions)

My guess is that it does'nt allow a select because the transaction has already been marked for rollbacking.


My solution.

Just moved the rollback to the end. i.e no operations are performed after the roll back.
Paul Sturrock
Bartender

Joined: Apr 14, 2004
Posts: 10336


Expected Result : Update 2 should be rollbacked after the select has been performed.As it runs in a "unspecified transaction context"

This is wrong I think. What the container should do is suspend the first method call, complete the second (using an unspecified transaction context) then continue the first. Any exception in the second will not roll back a transaction because there isn't one to roll back

What is it you are trying to do? If you want method two to enlist in the same transaction as method one use required or supports. If you want a temporary update manually manage the update, though I can think of no valid reason for doing this. Why are you performing an update you always want rolled back?


JavaRanch FAQ HowToAskQuestionsOnJavaRanch
Sudarshan Sreenivasan
Ranch Hand

Joined: Jun 28, 2007
Posts: 188

Why are you performing an update you always want rolled back


Once this update is performed the select will fetch certain rows , which needs to shown to the user , if the user is okay with it and approves it the changes become permanent.

If you want a temporary update manually manage the update


cannot do this as the framework requires me reach the data access layer only after having gone through the EJB layer

Any exception in the second will not roll back a transaction because there isn't one to roll back


Agree with this.I sort of want my method2 to be autonomous.The rollbacks should not affect my calling method.

However any operations including selects done after the rollback cause the Rollbackexception to be thrown.

Irrespective of the transaction attribute assigned to method2.

I have sorted it out as far as work is concerned , but its fun to have this discussion.
Paul Sturrock
Bartender

Joined: Apr 14, 2004
Posts: 10336

It sounds like you are maybe subverting the roll back behaviour of a database to be a quick way of performing a check you could otherwise do in code. This is liable to be a bit wasteful pushing extra load onto the database server. What wrong with changing the logic so you perform your select, update in memory in a client, show the update to the used then comit if accepted? Or are there database triggers that need fired that requires you you try the update?

Alternatively would it not be better to use some sort of staging table in the database?



cannot do this as the framework requires me reach the data access layer only after having gone through the EJB layer [

I don't see why this prevents you manually managing the update.

All this aside its beginnig to sound like what you really need is BMT not CMT.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: NotSupported TransactionAttribute
 
Similar Threads
Transaction attributes and unspecified transaction context
Topic: Big doubt! Spec Page 361 -- IllegalStateException for Supports attribute.
Big doubt! Spec Page 361 -- IllegalStateException for Supports attribute.
doubts in mock exam questions.
record updation in entity beans with attribute "never"?