Hi
Comments below
David Lowe wrote:
>
> my 2 cents...
>
> I would disagree with you completely. Connection management, pooling, etc., has no
>place
> within the EJB spec. Are you trying to use connection closure as a mechanism for
>marking a
> client dead and reaping its state? What if the network (rather than kernel) of the
>peer is
Exactly the opposite. We want to ensure that the client stays alive
irrespective of the
underlying connection transport layer state. At the moment, whether a
socket is open
or closed seems arbitary.
Note that in these days of increasing dialup and intermittent
connections
people want to be able to drop the dialup line.
Lots of systems won't let you control this easily, others will drop the
line if there
has been no packet activity etc. Look at the Netscape mail client and
the amount
of effort which has been put into making that work off-line.
We also need control over connections for performance issues - so that
we can predict
large ammounts of activity an pre-open connections, so that we can close
un-needed
sockets etc.
> dead? (TCP won't notice). Planning to implement pinging yourself to check for
>liveness?
> What if I use HTTP, or firewall proxies of some kind? Trying to do DGC rather than
>completely
> separating the lifetime of state on the server from the lifetime of references to
>that state
> is a) difficult, and b) not likely to scale well. The problems re. DGC are well
>known. A
> portable app shouldn't have any reliance on the use of connections, and neither
>should the
> spec.
> -- dave
A portable app needs to be able to control the state of (dis)connected
itself, simply because of
the fact that users want this control. If the spec does not clarify
who's responsibility this is
(see my original message) then we will see so many private
implementations that this situation
becomes untenable. I shouldn't have to (e.g) steal the underlying T3
connection in Tengah
simply to tell the transport layer that its connection is not needed for
a while.
>
> Joel Crisp wrote:
>
> > Hi
> >
> > Thanks for your reply.
> >
> > I would contest that connection management should not be mentioned in the
> > spec, even if it is not part of the formal spec per say. If the spec is to
> > be practically useful - rather than just of academic interest - some
> > common behaviour needs to be available to the bean author.
> >
[DELETED]
Joel
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
