Eric Newcomer wrote:
> Hi Gregg,
>
> Thanks very much, this is very interesting
> information.
>
> It does confirm what I was trying to clarify in my
> original email - in this model unless the client is
> running a transaction manager (which seems unlikely
> for a phone) the phone is *requesting* the transaction
> not "executing" the transaction. I do not see
> anything here which defines how the client would
> actually execute the transaction, in fact this looks
> to be out of scope entirely.
I think we are mixing concepts here. The Jini transaction model is meant to
allow coordination of things happening in disjoint computer systems. This
means
that you absolutely have to take partial failure into account.
Thus, the phone, participating in the transaction, may or may not be talking to
a transaction participant that is co-located with the transaction manager.
Thus, the phones interaction with the transaction has to pieces. It has the
basic steps of 2PC that it needs to move through, and it has the communication
of its intent to the other participants.
Yes, the participants are providing the semantic execution of 2PC. They have
to, because they are controlling the progress of a state change local to
themselves. How else would the phone participate in a transaction that
involved
the update of two different data stores that are on two different continents?
In my example, I was using the exported endpoint as the protocol conversion
point. It's not the transaction participant from a semantic perspective, but
it
is the implementation (as a delegate) of the TransactionParticipant interface
that Jini requires to see on the network, somewhere.
> The Jini transaction spec basically leaves it up to
> the participating objects whether or not to enforce
> 2PC semantics.
The spec lays out the allowed transitions. The participants need to implement
that logic. I don't see anything but bugs keeping that from happening. What
am
I missing in your statement?
> Again, this is fine as long as you do
> not need to recover update operations against multiple
> resource managers. While this provides greater
> flexibility for developers, it also introduces
> additional risk. This is a classic debate in the TP
> industry - how much to leave to the programmer's
> control and how much to guarantee in the software
> system.
This doesn't make sense to me. The programmer is providing a transaction
participant that is updating some arbitrary state. It may or not be a
database.
In order for that state transition to participate, there has to be software
around that transition that meets the semantics of the 2PC. When there are
multiple participants (I assume you are using resource managers instead of
participants in you terminology?), the transitions in the spec reflect what has
to happen. As a participant, the phrase "the paricipant must be as durable as
the data being changed" is the key. If you are providing access to simple ram
based updates, then your participant doesn't need to be able to recover it
participation in an running transaction if the data being changed can not be
durable across the same event as would cause the participant to disappear right?
A system architect would need to decide how each service capable of being a
participant would persist itself and the data controlled by the transaction.
There is a lot of flexibility allowed for here because that's what allows a
"working system" to be built instead of demanding a "maximal system".
> The OTS specification was created in a classic sort of
> compromise between OO people who wanted to delegate
> control completely to the developer and traditional TP
> folks who wanted the system to enforce the
> transactional guarantees automatically.
We can't have full blown XA implementations everywhere, and better yet, we
don't
need them.
> The difficulty in layering newer technologies onto
> existing TP technologies such as transaction managers
> and recoverable resource managers is that you cannot
> reinvent those artifacts. In fact the development of
> a truly reliable and bulletproof transaction manager
> is a very challenging task. Furthermore one is not
> going to cause Oracle, DB2, SQL Server etc. to change
> their behavior simply because you want to give the
> developer more flexibility - the database cannot lose
> a transaction, nor can it risk corrupting the
> customer's data or introducing inconsistencies within
> it.
Right, so with Jini, you can provide an external interface as a transaction
participant that local votes on the oracle transaction and progresses through a
2PC, mapping that into the appropriate calls. Thus, Oracle changes nothing but
now you have an extensible model which can allow you to do much more than you
used to.
> The Jini model does allow delegation to existing TP
> infrastructure, which is how it would achieve 2PC, but
> this means Jini depends upon that infrastructure for
> the exeuction of transactions. Nothing has changed
> here except the idea that the developer might want to
> relax the ACID properties and take control of the
> transaction coordination, but this idea does not map
> well to existing TP infrastructure, which isn't going
> to change any time soon.
If you consider that the only participant is the database server, or some other
enterprise application, then things look peachy because your just trying to
make
sure that a set of operations against a "service" are atomic. If you consider
that the world is bigger (as some systems designers are finally starting to do
with SOA architectures), then you start to realize that the complexity of many
main stream TP architectures is more of a burden than an asset.
If you've chosen to use Jini/Java as the backbone of your SOA, then you have a
neutralization layer that enables you to manage transactional behavior
anywhere,
without having to have an XA or JTA implementation from vendor X and another
from vendor Y which don't get along too well. You can provide work arounds for
the weak areas of each vendor and otherwise keep your architecture clean while
still tollerating the imperfections of software.
Gregg Wonderly
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
