"A distributed transaction is a transaction that updates multiple resource managers (such as databases) in a coordinated manner. In contrast, a local transaction updates a single resource manager. The two-phase commit protocol is a method of coordinating a single transaction across two or more resource manager" --says weblogic 6.0
I am having one bean deployed in weblogic server 5.1(WLm) of one machine(say machine M).Another bean deployed in weblogic server 5.1(WLx) of another machine(say machine X).
Another bean deployed in weblogic server 5.1(WLy) of another machine(say machine Y).
The bean deployed on WLm is controlling other two bean which
is in a different machines(WLx & WLy).This two bean doing
functnality in database operation(deposit and withdraw).
I am dealing with single database only.
I cannot able to accomplish the ACID properties, I mean
dosen't rollback even one fails.
What I have done is distributed transaction or local
transaction.(Since am dealing with single database).----(1)
But I can able to accomplish the ACID properties, I mean
rollback even one fails, when beans on two machine(WLx & WLy) on single machine.And I keep controller bean is in WLm.
How this is achieved... ---------------------------------(2)
Thanks in advance
Although this is in the strictest sense a distributed transaction, I dont know of any currently available application server which can support this. Most distributed transaction setups today have the applications server acting as a Transaction Manager only. To meet your need the application server would need to also be able to act as a Resource Manager as well in order to be enlisted into a transaction started by another application server instance. At this time, I know of no application server on the market which supports this.
At Sybase I can say we have considered this but I dont know a product version or time frame for such support. For us due to our CORBA and OTS implementation this is much easier then for non CORBA based application servers.
Net net is I wouldnt hold my breath to see this kinda functionality anytime soon.
Internet Applications Division
Let's clarify the picture a little more:
Basic design: M bean wraps the X and Y beans in the some method (therefore transaction). Both X and Y hit against the same database. And you are using WLS 5.1.
If M, X, and Y are on the same WLS machine, you have no problem rolling back the transaction if one of X or Y fails.
If M is on one machine, and X and Y are on a second machine, you can still rollback the transaction.
However, when the 3 beans are on 3 separate machine, you lose the ability to rollback the transaction either X or Y fails.
Dave says <QUOTE>Although this is in the strictest sense a distributed transaction</QUOTE>, but I guess he means "in the strictest sense NOT a ...".
I am not surprised that scenario 1 above is sucessful, but am somewhat surprised to learn that 2 is successful, and more surprised to learn 3 fails even 2 succeeds.
Have you tried WLS 6.0, which should support distributed transaction involving more than 1 resource manager (database)?
First of all, it's an obvious limitation of the current technology that your scenario generates a distributed transactions. It's because of app servers, Jdbc Drivers, and database APIs in general (you couldn't do better even if you try to write C code through the database CLI).
Then it's a bad architecture that you had to spread your beans over different machine, or maybe the app server did it for you, in which case it shouldn't have let you make calls across the clustered instances.
Even if you manage to make the distributed transaction work in a particular app server, it's a tremendous waste of resources to have a distributed transaction instead of a local one.
So I recommend you to go back to the whiteboard, forget about EJB clustering and other stuff and try to keep it simple :
- Either a single machine, single JVM app server should do
- OR have a clustered environment, but make sure you don't have intra cluster calls like you described. Tough task because there's no standard way, but I believe a reasonable app server vendor should allow you to do it.
Middleware clustering, when the database can handle the load without being clustered (most do), is a sure sign that you have either : a bad application server, a bad architecture/design/implementation, or all of them together.