On Jan 11, 2008 4:43 AM, James Masters <[EMAIL PROTECTED]> wrote:
> In my naivety, it seems to me that conceptually a script would normally have
> a single shared connection for all it's calls.  Both from a tidiness point
> of view and also because I guess it would be better performing not to keep
> opening new connections (?).  What is the reason for having the default
> opening a new connection and not using an existing one?
> i.e. Are there any disadvantages in having a single shared connection for
> multiple calls?

If there were one obvious default behavior for managing db connections
that everyone expected, I'd do it.  Trouble is, there is no single
"best" policy, and everyone's expectations differ.

The existing "default unshared" behavior is intended to prevent
situations where a user unfamiliar with transactions does a commit or
rollback in one part of his code and is surprised to find that it
committed (or undid) work done previously in another part of the code.

This behavior is "obvious" if you a) understand transactions, and b)
are fully aware that database connections are being shared.  But
you've seen, many people don't actually know what the default db
connection behavior is in RDBO, so even if they understand
transactions they still may be surprised by strange bugs that cause
"spooky" effects in widely separated pieces of their own code.

That's why I think the default unshared behavior is the "safest" in
that sharing now requires some action (and therefore some thought) on
the part of the developer. The required action is simple (usually a
line or two of code in one place, as you've seen) and I like the fact
that it forces the developer to actually formulate and stick to some
sort of overall policy for connection sharing, rather than just
winging it without really understanding what's going on.


Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
Rose-db-object mailing list

Reply via email to