AW: [OJB-developers] ConnectionMAnager and more

[Mahler T. <tho...@it...>]

Hi all,

> -----Urspr=FCngliche Nachricht-----
> Von: Christian Sell [mailto:chr...@ne...]

>=20
> I would like to re-emphasize my suggestion to move connection=20
> management
> issues out of OJB's domain. There are other=20
> tools/infrastructures which
> already make this their focus and do a very good job. Lets=20
> focus OJB on
> object/relational mapping.

That's a good argument. I want to support only simple things like =
obtaining
JDBCConnections through a JDBCDriver or to request Connections from a =
JNDI
lookup.

I think it's a good idea to make the ConnectionManager pluggable to =
allow
implementations that use other mechanisms to obtain JDBCConnections.

> I would even suggest dropping the per-class
> connection mechanism, as it is very problematic without 2=20
> phase commit.
>=20

You are right. Some time ago someone suggested to implement 2P commit =
to
make the per-class connection mechanism safe.
I answered that I would rather drop the per-class mechanism than to =
struggle
with a 2P solution inside OJB.

My suggestion: just drop the per-class JdbcDescriptors from the =
repository
DTD. Thus we have a clean API. On the other hand we may provide the
per-class mechanism as a non-documented feature for special =
applications
scenarios (e.g. transfering objects between databases). =20

> anyone?
>=20
> regards, Christian
>=20
> msg 1
> =3D=3D=3D=3D=3D=3D
> sorry for jumping in (but I guess thats what we're here for).=20
> I personally
> dont think ConnectionManager is worth much consideration. IMO=20
> connections
> sould not be "managed" inside OJB at all. Also, I feel the idea of
> maintaining connection information (optionally) on a=20
> per-class level is
> rather questionable.
>=20
> reason 1:
> management of transactions becomes rather difficult, if you=20
> have objects
> from classes with different connection specs participating in=20
> the same OJB
> transaction. This would require a full 2PC implementation and=20
> coordination.
> I dont see OJB addressing this, which can cause major problems.
>=20

see my comment above.

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

OJB keeps all Connections open to have the prepared statements "hot" =
and
avoid multiple prepares.

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

In it's early days the PersistenceBroker did not have methods for =
beginning
and commiting transactions. It simply used the JDBC autocommit feature.

after introducing beginTransaction() and commitTransaction() I had to =
do all
this setAutoCommit(...) switching to allow clients to work with or =
without
PersistenceBroker transactions.

If we decide that client applications MUST call beginTransaction() =
before
any other PB API calls, we can drop this switching stuff.

=20

> msg 2
> =3D=3D=3D=3D=3D=3D
> I will introduce a cache-configuration element (something=20
> like that) under
> the class node in the new repository schema. If there is a=20
> class-specific
> element, use that, otherwise use the global default.=20

That's a good idea!

> IMO it=20
> is always good
> to maintain the cache on a per-class basis, as this is an=20
> easy and safe way
> to reduce Map lookup operations.

Yup!=20

Thomas

>=20
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>=20