>
> Here's one idea, but not sure it will work given that I don't understand
> much about your implementation yet. You could maintain a hashtable on
> the server, but instead of mapping from key {URL, EJB name), you could
> use the RMI OID of the previously deployed EJB as the key, mapped to the
> OID of the newly deployed EJB.
in jBoss 1.0 and jBoss 2.0 one of the ideas of Rickard was that the RMI
layer was common to the target beans (in the server in jBoss 1.0 and the
container in jBoss2.0).
This idea won't work for 1.0 (we can't tie the RMI OID) to the server we
might be able to do in 2.0 since the container now comes with its own
RMI object. I want to say that this "hack" is just too pretty to undo
;-)
The problem here is tying it to RMI and a possibility might be to use
"soft versioning" where you increase the version of the container being
deployed (not set by deployer or client, maybe seen by deployer) and
when the stub comes back it comes back with a field set in, say
ProxyContainer and equivalent in jBoss2.0.
This is what I had in 0.3 and it works just makes the container a bit
more evolved. That will work with the new architecture from RIckard's
idea, methinks.
marc
> If a request arrives from the client,
> you check the hashtable - if no entry found, you assume the EJB hasn't
> been redeployed. When the first request arrives from the client,
> assuming your architecture allows this, you can send the OID of the
> newly deployed bean back to the client so it will use it on the next
> request.
>
> Potential problems:
>
> 1) If you allow this "hot" redeploy on stateful session beans, you will
> lose the state of the previous bean and break the client. Likewise for
> an entity bean, unless it is resynch'd with the db before/after each
> method call.
>
> 2) You must guard against multiple redeploys that occur before all of
> the client references to the original bean are updated. For example,
> suppose you have 3 clients, c1, c2, c3, and they all access bean b1.
> You redeploy b1 twice, so you move from oid b1a -> b1b -> b1c. Assume
> the following time ordering of events:
>
> t1: b1a deployed
> t2: c1, c2, c3 access b1a
> t3: b1b deployed // this adds entry in hashtable of b1a -> b1b
> t4: c1 accesses b1 // server uses b1a -> b1b entry to find b1, server
> returns b1b oid to c1
> t5: b1c deployed // this adds entry in hashtable of b1b -> b1c
> t6: c2 accesses b1 // server uses b1a -> b1b entry, then uses b1b -> b1c
> entry to find b1, server returns b1c to c2
>
> By recursively checking the hashtable for mappings from previous
> deployed bean oid to next deployed bean oid, you eventually find the
> bean you are looking for. It shouldn't be a problem to keep the old
> mappings in the table in the case of redeploys because there should
> never be *that* many entries in the table. We'll only have one per
> *re*deploy, none on the initial deploy.
>
> Hope this makes sense - I'm very new to ejb and all this new techno
> still has me a bit underwater :)
>
> One final comment. If I correctly understood the potential problems I
> raised earlier, is this really worth implementing? Seems like its
> usefulness will be limited to select situations and the confusion of an
> additional feature may not be worth the payback.
>
> Regards,
>
> Rick Horowitz
> > >
> > >/Rickard
> > >
> > >ps. hm.. perhaps a mapping between the URL string and a plain sequenced
> > >number.. or use RMI Activation?
> > >
> > >--
> > >Rickard �berg
> >
> > Hi Rickard,
> >
> > I don't know how much overhead this will add to each method call but I
> > think it's an area it can be tuned a lot.
> >
> > Dreaming... dreaming... I have seen it would very interesting to have
> > different options when you undeploy a bean. I see two options :
> >
> > (1) "Soft undeploy" -> Old clients continue working with "old beans"
> > until they disconnect, then the bean is
> > destroyed. I think this only applies to
> > stateful beans.
> >
> > (2) "Hard undeploy" -> Old clients are disconnected, old beans destroyed
> > and any pending transaction is completed. This
> > applies to all kind of beans (stateless, stateful
> > and entities).
> >
> > Option (1) will be useful if you have made a change in the code and you
> > want your clients use it ASAP but without forcing a disconnection in
> > current clients.
> >
> > Option (2) will be very useful when the change made to the code, doesn't
> > allow to coexist (is correct this word?) old code with new code, a
> > dangerous situation if you have old clients talking to old code and new
> > clients talking to new code.
> >
> > I can imagine even a third option, but I don't know if it would be
> > possible :
> >
> > (3) "Terminator undeploy" -> Old clients are disconnected, old beans
> > destroyed and any pending transaction
> > rolled back.
> >
> > And maybe a message like this is showed on the screen... "Hasta la
> > vista baby" :-D
> >
> > Is interesting this idea?
> >
> > Pedro Mota
> >
> > --
> > --------------------------------------------------------------
> > To subscribe: [EMAIL PROTECTED]
> > To unsubscribe: [EMAIL PROTECTED]
> > Problems?: [EMAIL PROTECTED]
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Problems?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
