I totally agree with Alexey,
In a corba like or even maybe all stateful protocols you just need to attach.
I see the danger but it is much easier for the protocol layer to keep
track of attachment resources and know when to release than for the basic Grizzly Framework
I think the best Grizzly can do is maybe like has been suggested to have
a nice closeable method.
(and maybe in debug modus attach an last ready timestamp to Connection)
many Greetings
John
-------- Original-Nachricht --------
> Datum: Thu, 19 Jun 2008 13:38:52 +0200
> Von: Oleksiy Stashok <Oleksiy.Stashok_at_Sun.COM>
> An: dev_at_grizzly.dev.java.net
> Betreff: Re: [Grizzly2.0 - Issue 3] Attaching a Connection object to the SelectionKey
> This is my favorite :))
>
> Talking about attachments, currently in Grizzly 1.x we use following
> attachment types:
> Long: is used *all the time* for *all* server side connections
> ThreadAttachment: is used for SSL, ProtocolParser
> CallbackHandler: for *all* client side connections
>
> as we see even if we don't like attachments, we use them quite widely
> even in current Grizzly code, especially Long and CallbackHandler.
>
> So, what I propose is to generalize attachments, so it will be always
> one type of attachment: Connection, where it will be possible to save
> some connection related state.
> Connection will be some small object, which, by default, will not have
> any ByteBuffers or sockets or whatever associated with it. So for me
> having Connection as attachment will be almost equal to having Long
> attachment.
>
> But what Connection will propose us - is general way of accessing
> connection state attributes and common IO operations implementation.
>
> So at one side Connection, by default, would be almost as light as
> Long, or, if developer will decide to store the connection state - as
> functional as ThreadAttachment.
>
> Talking about possible nightmare - I think possibility of having
> resource leaks with Connection is absolutely the same if compare with
> ThreadAttachment. Because it's possible to save ByteBuffer to
> ThreadAttachment and forget to release it - so, I don't see any
> additional danger Connection will bring.
>
> One thing we need to make sure is that Connection, by default, will be
> really light object without any important resource associated.
>
> Thanks.
>
> WBR,
> Alexey.
>
> On Jun 18, 2008, at 21:04 , Jeanfrancois Arcand wrote:
>
> > Salut,
> >
> > my nightmare is back[1] :-) Alexey is proposing to attach a very
> > simple object called Connection to the SelectionKey. This Connection
> > object object would persist some connection information when the key
> > is registered back to the Selector. I've never been a fan of
> > attaching object to the SelectionKey, and I do think we can
> > reconstruct those objects between transaction instead of attaching
> > them.
> >
> > Alexey's proposal is also to get rid of ThreadAttachment (hide the
> > concept to the users). I was under the impression it was a good
> > idea, now I'm no longer sure :-)
> >
> > What peoples thinks?
> >
> > A+
> >
> > -- Jeanfrancois
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> > For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
--
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser