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