On Nov 7, 2009, at 5:58 AM, Quintin Beukes wrote:
Hey,
I might have asked this question before - though I can't find the
mail, so
if I did, I deleted it.
Either way, I was pretty amazed yesterday. So much I'm not sure I
imagined
it.
I had an open application that I've done some EJB invocations in.
Then I
redeployed my EJBs. I went to the app and was able to continue without
problems. With GF I had to restart the app. Does OpenEJB handle this
as I
think it did?
Not all connection hangups are equal, but we do have some code in
there to deal with this where we are able to detect it.
Secondly. This I know i've asked, though I'd just like to confirm it
for
G2.2 with OpenEJB 3.1.2 and expand on it.
a) Does OpenEJB, when you create a remote context keep an open
connection at
all times, or does it get a session key and have a detached session
context?
We keep a small pool of open connections (5 by default) for as long as
the server will let us (5 minutes by default).
b) If in either of these cases a connection fails, will it
transparently
attempt to recover from this?
Depends on the hangup. TCP is notoriously resilient and will not
report a connection as closed for several minutes sometimes even when
it is cleanly closed on the server side. If a network goes down,
either side will try really hard not to fail and will happily accept
any bytes you wish to write -- only when reading will you get a
exception.
So on the client side we will automatically retry if we are unable to
write the request. If we are able to write the request but reading
fails, than by default we will *not* retry as we have to assume the
server received the request -- we do not want to run the risk of
potentially executing important transactional work twice.
We do have some undocumented dip-switches and flags that will enable
connection "testing" ping/pong logic between the client and server as
well as the ability to retry even when a full request write does occur
but response read fails. I can give you some pointers if you want to
dig around and help document them :)
-David
