"Instance per Transaction Policy" and Commit Option A

[hugbert]

Hi,

On a lot of places I read:

The JBoss developers are currently exploring ways to allow commit option A as well (which would allow the use of caching for this option).

Is it possible to use commit Option A with Instance per Transaction Policy?

Thank you

Regards

Hubert

[wdfink]

Hi again,

It will make no sense to use 'Instance per transaction' with commit-option 'A' because there is no caching after the transaction is finished.

What do you want to achieve? Maybe I can give you a better answer

[hugbert]

Hi Wolf-Dieter,

Well, I would appreciate very much, if you could give me some advise on this issue :-)

My situation is:

We changed from JBoss 4.2.2 to JBoss 5.1.

In 4.2.2 "Standard CMP 2.x EntityBean" was defined with commit-option B, we changed that to commit-option A,  use TRANSACTION_READ_COMMITTED and could live with this.

We use Derby DB, and have an environment (workflow) where a deadlock is possible. It is also possible that two users have the same DB records in access, the first committer wins, the other will get errors, that the desired action is no more available.

In JBoss 5.1 "Standard CMP 2.x EntityBean" derives from "Instance Per Transaction CMP 2.x EntityBean" wich uses commit-option C by default.

I red that this "can totally wipe away deadlock and throughput problems caused by JBoss's default locking policy", with drawbacks regarding "stale beans" and commit-option B or C.

All our beans use "Standard CMP 2.x EntityBean" except one. I changed the bean that represents the current step to use "Standard CMP 2.x EntityBean with cache invalidation" wich uses commit-option A by default. But this is "best guess", I am not sure if this is the best available option.

The isolation level is set to TRANSACTION_READ_COMMITTED.

Since Derby is not the fastest DB I would like to figure out if this is the correct configuration for us, or if there are ways to optimize this. And since this is not an easy issue (to me) I am unsure about the best configuration.

Any advice will be appreciated

Thank you

Hubert

[wdfink]

I have used my own configuration annotated by the implementation, e.g. one eith cache, one with per Tx and another with a row-locking for Oracle.

With a new JBoss version I decide which configuration I use as base and create my own config.

This will avoid some unexpected results.

If you can acept the behaviour you should use the old behaviour, if you change the strategy of caching and locking your application behaviour might unexpected. In your case I suppose it is a single instance and no cluster, for this it is ok but you have to keep in mind that the behaviour is different if you use a JBoss-cluster.

[hugbert]

Wolf-Dieter,

Thank you, I will do some experiments when I have the time.

Regards

Hubert