NotSupported TransactionAttribute

[Sudarshan Sreenivasan]

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]

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]

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]

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?

[Sudarshan Sreenivasan]

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]

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.