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.
Joined: Jun 28, 2007
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
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.
Just moved the rollback to the end. i.e no operations are performed after the roll back.
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?
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.