Forgot to reply to this mail, which raises interesting points.
More inside.
Le 4/11/12 10:38 PM, Alex Karasulu a écrit :
On Wed, Apr 11, 2012 at 4:04 PM, Emmanuel Lécharny<[email protected]>wrote:
I think we should add some mechanism in the server to check that
automatically, to avoid doing it by hand (there are hundreds of tests to
check...). One solution would be to keep a track of every cursor
construction in a HashMap, and to remove them when the cursor is closed.
The remaining cursors are likely not closed.
It would be nice to have a Cursor monitor that every opened Cursor
registers with but this needs to happen automatically. Then when out of the
creation scope the Cursor is expected to be closed and if not this is
handled automatically. However does creation scope work well since
sometimes we create Cursors and pass them up?
We do have a monitor, which is currently used to check that the cursor
is not closed when we try to use it. We certainly can use this monitor
for more than just checking such thing.
Now, the pb is that the scope is not as easy to determinate than for a
variable in Java. For instance, if we consider persistent searches, or
paged searches, or even an abandonned search request, the scope is
pretty wide...
Though we can have a set of rules that help us to close the cursor
automatically :
- if we get an exception during a SearchRequest, then the cursors must
be closed immediately. As soon as we store the cursors into the
SearchContext, this is pretty easy to do
- an AbandonRequest will close the cursor automatically too (getting the
cursor from the abandonned request)
- when we process the SearchResultDone, we can also close the cursor for
the current search request (this work for PagedSearch too)
- for pagedSearch, if the user reset the search by sending 0 as the
expected number of entries to return, then the cursor will be freed
- for persistent searches, as it will be closed by an unbind or an
abandon request, we are fine
- when a client unbinds, then all the pending cursors will be closed.
All in all, we have everything needed to close the cursors
automatically, assuming we keep all the cursors into the session.
On the client side, this is another issue... As cursors are created by
the client code, we have no easy way to determinate when we should close
the cursors, except when the connection is closed or an abandon
request/unbind request is sent. Of course, when the server returns a
searchResultDone we could also close the cursor. Remains the situations
where the client has fetched some entries (but not all), and haven't
unbind nor abandonned the search.
In any case, this is less critical as we don't have to deal with the txn
layer. The client will just blow away with some nasty OOM sooner or
later... but this is not worse than what we get with NamingEnumeration
in JNDI, nah ?
Have I covered all the server options ? Or did I miss something ?
This sounds like something that can be handled nicely using an aspect
oriented solution. Now these things are heavy if you use AspectJ or
something like that but other simpler solutions exist to bytecode splice
compiled code to automatically handle these things. Maybe our past
experiences with Aspects might make us reconsider.
A bit overkilling, IMO?
Thanks !
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
