> > To me, distributed transactions goes hand-in-hand with clustering.
> Clustering is
> > of quite limited use without it.
>
> Disagree. Clustering is still very very useful. Once a remote
> call reaches a
> cluster node all interaction will be local, at least in the first
> version of
> the clustering, so there is no need for distributed transactions
> initially.
I had missunderstood the question, yes rickard is right, the distributed TM
buys us nothing in clustering provided we do the right thing.
The right thing is of course to separate the naming space that is global and
the local name space. If we make sure that the local namespace is inVM (as
it is today) then all the beans you will start from the first bean WILL run
in the same VM. BTW I would argue that this is the right way to run your
application *anyway* because of the speed increment that you will see. In
other words, the important part is the clustering of applications *as a
whole* on one stack and replicate the stack in clustering as opposed to one
part of the application in one set of machines and one other part on another
set, due to the RMI overhead. BTW it is the same approach we are taking
with jboss+tomcat, that we will replicate the stack of pancakes interceptors
in many VMs and that is the simplest way to do it and the fastest.
The part is still to be designed (we are designing it *right now* with
Rickard) is the global namespace and its clustered visibility and the kid
has a few tricks up his sleeves (and as long as I can understand and
validate them, since well you know ..., it will be in). That is what we
intend to do for the final jboss2.0. That is a change of plans btw before
we were going to put clustering in jboss3, now I want to make jboss2.0 a
REAL PRODUCT, that reaches the best on the market. So clustering, if you
reread my TODO mail is #1 priority... IT WILL BE DONE.
<theory and soap box>
back to the TM distribution and extra-VM. Be aware that jboss2.0 already
today does "distributed" transactions in VM in the sense that complex B2B
calls with many many beans do take care of the transaction stuff. Check the
testbeans and you will see we do lotahoops test on the transaction (and THAT
is what we want to fully test). However in the order of priority of
features in j2ee, i don't see the distributed tx real high. Right now I
believe that 90% cases are taken care of with the *ultra-fast* TM manager
that we have in. Rickard, Myself, and now Ole are actively working on
making that a simple yet fast and powerful TM for ALL inVM needs (and some
more). I don't see our constituency yelling "WE NEED DISTRIBUTED TX TODAY",
for the simple reason that folks that REALLY use this usually are found at
WebLogic/WebSphere (when WS works :). It is my belief, but maybe I am
mistaken and feel free to correct me, that the TM in place is a "good
enough" solution for the functional needs and a "better than enough"
solution for speed :). Again if that is not the case, voice your opinion
and *show* us an application you want to do manhana with the distributed Tx.
I am not saying these don't exist, they do, all I am saying is show me the
need *here and now*.
Finally I do believe that people need to understand how to use distributed
inVM component transactions (as we have today in jboss2.0) before we can
move to distributed extraVM transactions.
</theory and soap box>
>
> /Rickard
>
>
>
>
