Well, I thought I'd update everyone on my progress.

I've went to using a Singleton Connection Manager and a
Connection Pool.  Things really sped up my application where
I was grabbing a count of records multiple times.

But, it seemed that after 100 or so records, it would grind
to a halt, and eventually error out causing my
PreparedStatement to not function.

I did some testing and debugging and found that using just
Statement instead of PreparedStatement fixed the problem,
and a routine that took 3 minutes was now down to 10
seconds, mainly because of reusing my connections.

Then after some research on the net I discovered that there
is a bug that causes the error I encountered when using and
ODBC bridge.  So for now, just using a Statement is fine
with me.

I'm still having problems understanding the scope of how the
connection pool works.  Coming from the AS/400 where you
have jobs/activation groups that define the scope of
applications, understanding how a singleton object works is
still a bit confusing.

For example, if Joe runs an app that creates the connection
manager, then mary runs the same app, where does the single
instance of the object come into play.  Since they are on
different machines, do they each have their own connection
object inside their own JVM?  And in this case the only
benifit of the connection mananger and pool is reuse of a
single connection?

I guess it makes more sense in a servlet environment where
the connection manager is created on the server and multiple
requests can share connections and pools.  But are there any
other cases where the benifit will come into play?

So, is the "scope" of objects really inside each JVM that is

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2020 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].