Re: Re: Re: Re: Re: J2EE is too complicated - why not Perl?

[eduardo]

I have... across a mainframe / oracle / mssql boundry. It was not exactly the most fun thing in the world I've ever done, though I am reticent to admit (btw, I don't like java on a "personal preference" level), using Java did make it considerably easier. The mainframe vendor (IBM) already had a great many objects we could use to interface with MQ and CICS... Oracle behaved in an intelligent manner (they have too much invested in java to not at least *attempt* to behave in an intelligent manner), and the MSSQL work... actually, now that I think about it, someone else completely did that work :)

i'm not saying that it's not likely and possible that if such a framework and series of libraries existed for perl, it wouldn't be equally suited. i just *personally* have no experience with perl on that level, nor have I successfully in my googling found a vendor (or preferably vendors) that provide a perl framework with such functionality. *sigh*, what a shame.

[perrin]

If I had to do this in Perl, I would look at what the database vendors have to offer. Oracle and IBM both sell products for two-phase commit across multiple databases from different vendors. They also both implement the XA standard.

Frankly, it doesn't sound that hard to build a very basic transaction monitor that would do two-phase commit across XA databases, probably tracking state with a local transaction-capable database like SQLite. The thing is, it's probably not worth the trouble to build it. There is just so little call for this sort of thing in real-world applications. Most companies are trying to do simpler things, like basic replication. When something comes along that could conceivably be done with two-phase commit, even the DBAs typically choose to go with something less safe but much simpler. I suspect the main customers for distributed transactions are the financial industry.