[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Transaction support
Konrad Krafft wrote:
> I'm interresting in implementing Transaction-Support for the
> If you agree with it, I will first plan, what to do.
> - general transaction ability of xmlBlaster
> 2phase commit
> long transactions
Very interesting, as we plan to support stateless
protocols like email, http, etc. transactions
over days or longer are very interesting ...
> commit, rollback, recovery etc mechanisms
> nested transactions
'The Principles of Transaction Processing' (Morgan Kaufmann, 1997)
provides a good overview of TP Monitors and their underlying
technology (but i haven't read it)
> - XA-Support
> How become an XA-ResourceManager?
> find several transaction monitors/managers with XA-Support
> to test with.
for some informations.
Perhaps we should implement a little TP-Monitor
to test our implementation (in fact we need a tool
to load balance multiple xmlBlaster servers).
Orfali (Client/server survival guide) uses the terms (P. 344)
Transactional queues (IBM's MQSeries, BEA's MessageQ)
Transactional publish and subscribe (Tuxedos EventBroker)
> - OTS-support
> How become a transactional object
> Greetings from Konrad
Who is participating the transaction?
- only the middleware?
- The message invocation forces the recipient program
to join the transaction?
I have no closed picture about this topic yet.
Could you provide some simple design ideas as soon
as you know enough (a little picture)?
You may publish it directly on the xmlBlaster homepage.
(Just check it out with cvs).
ruff at swand.lake.de