John ROM wrote:
> I totally agree with Alexey,
>
> In a corba like or even maybe all stateful protocols you just need to attach.
>
Yes, that certainly has been my experience (in CORBA).
> 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
>
Generally that's true.
> 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)
>
I agree, and I think we briefly mentioned this in the last Grizzly meeting.
Grizzly should be able to close resources associated with a connection,
and the best way to do that is to have such resources implement Closeable.
For example, the Grizzly connection cache will close idle connections, and
so it must be able to guarantee that resources associated with an idle
connection
are reclaimed.
Similarly, if the protocol decides to close a Grizzly connection, all
Closeable
resources associated with that connection should be closed.
One of the ideas we are playing with is basically to use a generically-typed
attribute class to associate state with a Connection (this was discussed on
the Grizzly alias on 2/15/08-2/19/08). This would work something like:
static final Attribute<Foo> foo = new Attribute<Foo>( Foo.class,
"FooAttribute" )
Then we can access the attribute as:
foo.get( connection )
and set it as
foo.set( connection, fooValue )
If Foo implements Closeable, it would be easy for the Connection close
code to iterate over all attributes, closing those non-null attribute
values
that implement Closeable.
Also note that the implementation amounts to an ArrayList associated
(perhaps)
with the SelectionKey attachment. It would be easy to ONLY associate the
ArrayList in those cases where an Attribute is actually set, so if the
mechanism
is not used, there is no Attachment overhead.
Thanks,
Ken.