How does Kodo manage DB connection pools?

Question

Hi,
As per the documentation, JDO options MinPool and MaxPool are no longer
part of the specification. I expect this means the JDO implementation is
supposed to manage database connection pools appropriately. Now, I would
like to understand Kodo's approach to this, and whether I have any control
on pool configuration at all via the deprecated MinPool and MaxPool
properties -or are these properties simply ignored.
On a related topic, I am confused about the effects of closing
PersistenceMangers after every use, from a performance point of view (if
the connection pool is not managed by Kodo, am I incurring additional
overhead by not re-using a PersistenceManager?). I have read in different
places in the documentation that it is good to re-use PersistenceManagers
as well as the fact that although PersistenceManagers are
garbage-collected and connection resources freed as a result, it is
recommended to call close() on them anyway. Bottom line, are there any
side-effects to religiously asking the PersistenceManagerFactory (I have
several, one each for the different data sources I use) for a new
PersistenceManager at the beginning of each method and calling close() in
a finally{} clause?
I'm sorry if this has been answered elsewhere - I'd appreciate it if you'd
just point me to the discussion if so.
Thanks.
-Krishna Choppella
Digital Harbor, Inc.

Answer 1

would like to understand Kodo's approach to this, and whether I have any
control on pool configuration at all via the deprecated MinPool and
MaxPool properties -or are these properties simply ignored.Currently, Kodo uses the MinPool and MaxPool properties to configure the
JDBC connection pool. Starting with version 3.0, Kodo will use separate
pooling properties.
Bottom
line, are there any side-effects to religiously asking the
PersistenceManagerFactory (I have several, one each for the different
data sources I use) for a new PersistenceManager at the beginning of
each method and calling close() in a finally{} clause?Well, you miss out on the simple object caching employed by PMs. Each PM
keeps a cache of the objects it manages. Reusing a PM allows it to build
up a bigger cache, and makes calls to getObjectById and 1-1 relation
traversals faster.
Additionally, each cached object maintains state in its persistent fields
(subject to the RetainValues setting and other settings), so retrieving
object state can be faster when the object is already cached and has
already been read.
However, if you employ Kodo's L2 caching plugin (Performance Pack), then
you get all these benefits regardless of whether or not you re-use
individual PMs.