Well, let me recommend using jboss. (or possibly another app server). The
jca stuff combined with the ejb containers lets jboss track which
connections were obtained by which ejbs, and if you leave one open when
your method call returns, you can get jboss to close (the handle) for you.

This is actually contrary to the jca spec, but more useful and easy to
implement. Right now jboss has a "spec compliant" flag for this,
defaulting to this behavior.

IMO it will be extremely difficult to impossible without intercepting (by
AOP or other means such as jca framework and ejb container) all methods
calls into your object (and the returns) and all connection allocations,
and associating these.

david jencks

On 2003.04.04 09:02 Roman Rokytskyy wrote:
> Mark,
>
> > Short response, would be why not change? :-). long answer to also
> > follow :-).
>
> :)
>
> > > Well... this is a bug, and it should be fixed in driver and not
> > > worked around by not closing the statements.
> > >
> >
> > I did think that it might be nice to have something that would
> > explictly display what resources jayBird did have allocated. The
> > error eventually came from firebird server failed to allocate
> > resources, but jaybird (or the server) didn't have an easy way to
> > indicate it already held lots of stmt resources.
>
> I am playing a little bit with AspectJ and hope to create a couple of
> aspects for this task. When you build driver via AspectJ, you will get
> full tracking with places where connection was opened, closed, etc.
> Same about statements, result sets, etc.
>
> > > What about closing the connection?
> >
> > Well that worked, but it took a long time to figure out that was the
> > problem, abstraction and layering made it fairly dificult to
> > precicely pin down what resource was not being released.
> > (everyting was being released according to automatic java rules -
> > except that FBStatement needed an explicit close() rather than
> > having an automatic close on loosing scope - which is what i think
> > should be considered).
>
> Nobody guarantees you that your statement will be garbage collected.
> This is stated in Java Language Specification. VM decides when to do
> garbage collection. They only guarantee you that reference will be not
> reachable, but it can live in memory forever. So, to be sure you can
> add some "protection" layer in AspectJ (or any other AOP thing, even
> BCEL) that tries to close any visible statement reference before you
> exit a method. But... this is same as ignoring C++ warnings, better
> don't...
>
> > Well yes, I agree sort off, it's nice to explicitly know about open
> > statements, but when it's this reference that is the only link that
> > holds them open, wouldn't it be nice to then close them.
>
> Probably, but we have no control on it. Unfortunatelly you cannot get
> number of references on an object (at least from what I know). So, in
> driver I do not know if it is referenced or not.
>
> > It would be nice if when they went out of scope these stmts cleaned
> > themselves up and I think weak references would help do that.
>
> References will be cleaned, but this does not mean that they will be
> garbage collected. They _might_ be garbage collected (if GC decides to
> delete them or they can be recycled if VM decides it makes sense).
>
> > loosing scope and automatically disposing is meant to be an
> > advantage of java I might add :-).
>
> Sorry, but I do not see how loosing the scope leads to a
> Object.finalize() call. If this is the case, then sure. But I will
> believe only Java Language Specification citing.
>
> > And assuming most programmers are stupid (as is the general case -
> > and certainly in my case) why not handle these as weak references.
> > Is there real downside to doing it this way, and to using weak
> > references - as it would avoid that class of error completely?
>
> Weak reference means that if some object is only weak referenced, it
> _can_ be garbage collected.
>
> > But my motivation is more because just using the standard jdbc and
> > my own layer the problem was hard to diagnose.
>
> True, but this is also a style of coding. On Firebird conference I
> will introduce new pool and explain what coding style should be used
> in order to be clean. General idea: you have connection pool with
> prepared statement pooling; you prepare statement each time you need
> it and close right after you finished working with it. And all this
> standard JDK 1.3.1 and JDBC.
>
>
> > In my case (to help explain why I get such a simple error) it's
> > hidden within an instance of an Iterator,object which didn't
> > explicitly call the .close() object when scope was lost, and that
> > depended upon the whim of the user of reading until the end of the
> > result set.
>
> Sorry, but loosing the scope will not help you. :(
>
> > So to make it easier for the novice user, is there any inherent
> > problem with having connection.activeStatements as a weak
> > references, then even of the users is not real bright, they will
> > work ok, even if they do not explicitly have to close them.
>
> Or we will print messages with big red letters: "You allocated
> statement at line 67 and closed connection at line 88, but statement
> is still open". I will try to find a solution for loosing the scope
> too (probably with AOP).
>
> > (BTW: this generate code worked fine with MSSQL, Oracle 817, and the
> > JDBCODBC, so Im assuming they work this way)
>
> Interesting... Can you somehow check this (for example with that tool)?
>
> Best regards,
> Roman Rokytskyy
>
>
>
> To unsubscribe from this group, send an email to:
> Firebird-Java-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>