RE: [OJB-developers] ConnectionManager

[Bischof, R. <rai...@ed...>]

Christian,

re 1:
OJB does manage multiple connections to different DBs but it does not
implement a full 2pc. This of course may introduce inconsistencies in the
DBs if OJB runs into trouble when commiting a transaction on multiple DBs.

re 2:
I also see that OJB uses only a simple caching for connections and does not
close connections (at least I haven't found that also). It keeps the
connection open al time. For me not a big deal but in other environments
(e.g. public Internet site) this might be a problem

I personally would also favour managing connections outside of OJB but I
guess Thomas intended this as a feature to map different objects to
different DBs. 
I think if we can switch the internal connection caching off to have the
ConnectionFactory called for each new transaction it would be OK. If the
ConnectionFactory is enhanced to not only create connections but also close
them you have full control over the connections.


Btw:
You rote this mail to me personally although I guess it was intended for the
dev-list. The list-mgr is somewhat strange as you can't just hit the
reply-button ;-)

rb

-----Original Message-----
From: Christian Sell [mailto:chr...@ne...]
Sent: Montag, 12. November 2001 19:53
To: Bischof, Rainer
Subject: Re: [OJB-developers] ConnectionManager


sorry for jumping in (but I guess thats what we're here for). I personally
dont think ConnectionManager is worth much consideration. IMO connections
sould not be "managed" inside OJB at all. Also, I feel the idea of
maintaining connection information (optionally) on a per-class level is
rather questionable.

reason 1:
management of transactions becomes rather difficult, if you have objects
from classes with different connection specs participating in the same OJB
transaction. This would require a full 2PC implementation and coordination.
I dont see OJB addressing this, which can cause major problems.

reason 2:
you are bound to get into conflicts with runtime infrastructures (Connection
Pools, J2EE containers) which make exactly this (management and coordination
of external resources) their primary focus. Along this line, I havent found
any place where connections are closed in OJB. In a pooling environment (any
app server) this is a major issue, as connections should always be closed
(and thus released to the pool) as early as possible (i.e. immediately after
commit/rollback).

BTW, why is PersistenceBrokerImpl calling setAutoCommit(true/false) all the
time? Setting it to false once and for all should suffice, shouldnt it?

Christian's 2c

----- Original Message -----
From: "Bischof, Rainer" <rai...@ed...>
To: "objectbridge" <obj...@li...>
Sent: Monday, November 12, 2001 11:25 AM
Subject: [OJB-developers] ConnectionManager


> Thomas,
>
> what about making the ConnectionManager pluggable?
> This would enable me to use user specific connections. E.g. in
> getConnectionForClassDescriptor I determine the user session that the
> currently executing thread is working for and return a user specific
> connection.
> The already pluggable ConnectionFactory does not really solve this as it
is
> only called once to create a connection for each classdescriptor.
>
> The problem is that we have to use session specific connections since
there
> is no Dummy ID the application can use for all user requests. This is
> because of security restrictions in our environment.
>
> Any objections?
>
> Rainer
>