On 2001.08.16 15:35:22 -0400 Jason Dillon wrote:
> > I've been thinking a little bit about a jca adapter to a javaspace, set
> up
>
> Wouldn't you have to make an adapter to the jini tx service? or would
> the
> jca adapter to a space deal with all the tx under the covers (and ignore
> client requests to do it).
thinking about this a little more...
I think there are 2 options:
1. javaspaces as essentially mom. Here the "ejb" transaction is tied to the
jini transaction, so commit in the ejb container commits the put or take to
the javaspace. Someone else in a different transaction is responsible for
the other operation.
2. javaspaces as a more or less transparent or invisible way of doing
clustering/distributed computing, with something like rpc semantics. Here
ejb1 calls a method on ejb2 within transaction t1. ejb2 is on a different
server(s), say server2 connected by a javaspace balancing the load. The
container packs up the ejb transaction t1 with the method invocation info
into an entry, and puts it in the javaspace with a jini transaction that
completes immediately. (well, you could pack up several method calls and do
them all at once within the same transaction... although how you'd specify
this I have no idea). Some invoker on server2 is always trying to take
appropriate entries from the space, when it gets one it unpacks the
transaction and method invocation and does it. The return value follows a
similar route back to ejb1. Here there is one (t1) ejb transaction but 3
jini transactions:
-ejb1 puts entry
-ejb2 takes entry and puts method return value
-ejb1 takes return value.
I'm not quite sure how committing t1 is transmitted to all necessary
servers in this scheme. This scheme does supply good failover
characteristics, if ejb2 crashes in the midst of its method invocation its
jini transaction taking the method invocation entry will expire, so someone
else can try.
>
> > so you can use JAWS, with entity bean <--> entry. I'm not entirely
> sure
>
> I am not sure that you would want to use javaspaces for persistent entity
> storage, but perhaps someone does... not sure.
I wasn't thinking of persistent entity storage, I was looking for a
declarative code-free way of inserting entries into a javaspace. I wonder
how this would work with jms also.
>
> > yet what advantages this would have over jms. I'm also not clear about
> what
> > would fetch entries out of the javaspace.
>
> javaspaces are a different kind of animal than jms. the looks semantics
> of
> entries are vastly different. whiteboard-like apps are much better
> adapted
> for a space design than with queued messages, but either would work.
>
> I think it is all about options. If it is easy to do and or you have
> sufficient motivation to do it... then by all means =) I am positive
> that
> if there were javaspaces and other jini service plugins to jboss that
> people
> would use them. I sure would.
>
> > Maybe jca 2 will help, I think it is supposed to have "push" events.
>
> When is this due to enter reality?
Dont know -- it looks to me as if bea is designing the spec themselves and
releasing their implementation before the spec is released. This is only
my guess, I have no real evidence for this, but their jca stuff appears to
include some features from what jca 2 is supposed to cover.
>
> --jason
>
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
