AW: [OJB-developers] concurrent broker transactions in single vm mode

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

Hi Doug, Hi Daniel,

> -----Urspr=FCngliche Nachricht-----
> Von: Doug Currie [mailto:de...@fl...]
> Gesendet: Samstag, 2. Februar 2002 23:54
> An: ojb
> Cc: dn...@us...
> Betreff: [OJB-developers] concurrent broker transactions in single vm
> mode
>=20
>=20
> A broker pool is required to implement odmg concurrent transactions
> effectively.=20

I agree !

> Daniel Fernandez, you have been looking at a broker pool
> implementation; have you also thought about how to use this pool at
> the odmg level in single vm mode?
>=20

I don't know what exactly Daniel did, but I suggested to use the
PersistenceBrokerFactory to use a pool to reach fresh =
PersistenceBrokerImpl
instances to each ODMG transaction.

On transaction commit and abort the PB instance should be returned to =
the
pool.=20

> Having looked at this a bit, it seems to me that one broker per odmg
> transaction is a logical way to proceed.=20

agreed.

> Most code that needs to
> reference a broker is also grabbing a reference to a transaction.
> Unfortunately a 1-1 relationship between DatabaseImpl and broker in
> the current code is assumed by OJB.getBroker, but this can be fixed
> pretty easily I think.=20

IMHO this is a separate issue and needs some more thinking.

> Many places that get a broker from OJB either
> can just as easily get it from the transaction, or don't care what
> broker they end up with since they are just using it for access to =
the
> cache or metadata.

agreed.

>=20
> For example, sequences such as (e.g., OQLQueryImpl.execute):
>=20
>             // retrieve a broker instance
>             PersistenceBroker broker =3D =
OJB.getInstance().getBroker();
>=20
>             //obtain current ODMG transaction
>             Transaction tx =3D =
OJB.getInstance().currentTransaction();
>=20
>             // we allow queries even if no ODMG transaction=20
> is running.
>             // thus we have to provide a pseudo tx if necessary
>             boolean needsCommit =3D false;
>             if (tx =3D=3D null)
>             {
>                 tx =3D OJB.getInstance().newTransaction();
>             }
>=20
>             // we allow to work with unopened transactions.
>             // we assume that such a tx is to be closed after=20
> performing the query
>             if (!tx.isOpen())
>             {
>                 tx.begin();
>                 needsCommit =3D true;
>             }
>=20
> would get the trasaction first and become
>=20
>             //obtain current ODMG transaction
>             Transaction tx =3D =
OJB.getInstance().currentTransaction();
>=20
>             // we allow queries even if no ODMG transaction=20
> is running.
>             // thus we have to provide a pseudo tx if necessary
>             boolean needsCommit =3D false;
>             if (tx =3D=3D null)
>             {
>                 tx =3D OJB.getInstance().newTransaction();
>             }
>=20
>             // we allow to work with unopened transactions.
>             // we assume that such a tx is to be closed after=20
> performing the query
>             if (!tx.isOpen())
>             {
>                 tx.begin();
>                 needsCommit =3D true;
>             }
>             // retrieve the transactions's broker instance
>             PersistenceBroker broker =3D tx.getBroker();  // THE =
CHANGE
>=20
>=20

Yes, we will have to change all references to =
OJB.getInstance().getBroker()
to=20
OJB.getInstance().currentTransaction().getBroker()

I will change  all the ODMG code to consistently do this!=20

> If you need a hand with this let me know. I am interested in seeing
> the omdg layer improved with more concurrency for single vm
> applications.
>=20

Thanks for in depth analysis! We really have to get rid of these
bottlenecks.

Thomas

> e=20

([OT] why an 'e' not a 'D' ?)

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