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.
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.