Robert Resendes wrote:
I'm happy if you file this issue in JIRA.
OK.
Thanks.
Another question I have with regard to Mahalo is what happens if it
receives an indefinite RemoteException (such as ConnectException). I
found some language with regard to retries (5?) but I couldn't find the
retry logic, intervals between retries, etc. Can you help me out here
Robert what happens?
--
For this specific case (i.e. abort on the participant) or in general? If
it's the latter, then it will be a long discussion.
In general. As you might have understood from my postings on
"Controlling the object identification layer implementation" I'm trying
to come up with support for evolving persistent services that might go
off-line for maintenance purposes.
I believe a transaction manager service might be the right beast to
see how my ideas would work in practice as it is one of those services
that are a typical example not everything can be implemented as a
transient/replaceable service. I already have a clone of Mahalo where I
could start with experimentation. Also while implementing persistent
transaction participation support in Seven I try to think of how e.g.
the 2 new exceptions could be utilized when the 'transaction manager'
would throw OfflineException and ObjectIncompatibleException. Therefore
I like to learn more about how Mahalo does what it does, or should do
(?). I know I could dive into the code as I've done in the past when
implementing named transactions
(http://www.cheiron.org/utils/release/v0.2/api/org/cheiron/transaction/server/TransactionManagerX.html
[1]),
but I can remember I got lost often so some general info would be really
helpful.
Also currently when a service that utilizes persistent transaction
participation comes up and the local transaction participants have not
yet rejoined the actual transaction a ConnectException is thrown from
the container provided logic that acts as the transaction participant
proxy. The service when it initializes can obtain all the 'unconnected'
transactions for which it should provide a local transaction
participant and rejoins to be able to participate. I was wondering how
Mahalo would deal with these ConnectExceptions. From the code I was able
to digest that it ain't considered a definite exception, but I was not
sure for how long that is considered the case.
One part I still have to code in Seven is the logic that will call
getState() on the transaction manager service when it has been a while
that prepare has been called by the transaction manager on the
transaction participant. This code will also benefit from the 2 new
exceptions to make it more robust and accurate.
Given the fact that Mahalo is AFAIK the only public free transaction
manager service it would be handy to understand more of its retry
strategy. Although I have cloned it, but I want to keep its logic as
much as possible in sync with the River based version.
[1] I don't know whether there is interest to see this rolled into
River, but for me named transactions was a valuable enhancement to the
transactions specs to have a mutex service.
--
Mark
