Possible implementation plus possible problems - below...
[EMAIL PROTECTED] wrote:
>
> Rickard �berg wrote:
> >Hi!
> >
> >[EMAIL PROTECTED] wrote:
> >> I am askingf myself if redeploying would be possible without
> >> destroying/disconnecting clients. This would be "increible"
> >> (can't translate my spanish surprise :-)
> >
> >This isn't really as hard as you think.. I could do it right away, but
> >as always there are other consequences.
> >
> >Possible solution:
> >Currently each container has its own ContainerInvoker RMI object. This
> >means that the following context info is sent, which determines which
> >bean that should be invoked:
> >* RMI Object OID
> >
> >For each call we could send the URL of the deployment, changing the
> >context to:
> >* RMI Object OID of singleton invoker
> >* URL string + bean name
> >
> >When the singleton invoker gets the call it can look in some hashtable
> >for the key {URL, EJB name} and invoke on the result.
> >
> >So while the latter would allow clients to not disconnect on redeploy,
> >it does mean sending more contextual info on every call.
> >
> >If anyone has a workaround, please let us know.
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. 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]
