objectbridge-developers

[OJB-developers] using one transaction with multiple brokers

[Leandro R. S. C. <le...@ib...>]

Hi all !

Is it possible to spam one transaction to multiple brokers ??

1 case : using teh same VM
2 case : usinf diferent VM's

Basically I'd like to start one transaction on the behalf of one broker
and let other brokers participate one the same transaction !

-- 
Leandro Rodrigo Saad Cruz
IT - Inter Business Tecnologia e Servicos (IB)

Re: [OJB-developers] using one transaction with multiple brokers

[Thomas M. <tho...@ho...>]

Hi Leandro,

You really want to have a look at the OJB internals ? ;-) Ok, here we
go:

there are 2 transaction concepts in OJB:
1. the PersistenceBroker (PB) transactions. They are simple JDBC
transactions.
(see PB.beginTransaction(), PB.commitTransaction(),
PB.abortTransaction().
a PB instance can execute only 1 transaction at a given point in time.

So if you want to have multiple PB transactions at a time you need
multiple PB instances.
The ojb.broker.server.PersistenceBrokerServer is an example for this
scenario.
The ojb.broker.server.PersistenceBrokerClient uses a round robin scheme
to address multiple server to obtain multiple transactions. Refer to the
document http://objectbridge.sourceforge.net/system/clientserver.html
for details.

But: a PB instance can not participate in transactions of another PB
instance. (As they are merely JDBC tranactions).

2. There are also the object level transactions of the ODMG
implementation. You can do all kind of manipulations with those:
let multiple threads work with a given tx, or 
let one thread work with multiple tx, etc.
have a look at
http://objectbridge.sourceforge.net/javadoc/org/odmg/Transaction.html#join()
for details.

The OJB ODMG transactions use PersistenceBroker transactions only during
their commit phase. So there are no open JDBC transactions during a ODMG
transaction!

This will also allow us to easily integrate OJB into a 2Phase commit
environment. But this is not yet implemented.

HTH

Thomas

Leandro Rodrigo Saad Cruz wrote:
> 
> Hi all !
> 
> Is it possible to spam one transaction to multiple brokers ??
> 
> 1 case : using teh same VM
> 2 case : usinf diferent VM's
> 
> Basically I'd like to start one transaction on the behalf of one broker
> and let other brokers participate one the same transaction !
> 
> --
> Leandro Rodrigo Saad Cruz
> IT - Inter Business Tecnologia e Servicos (IB)
> 
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers

Re: [OJB-developers] using one transaction with multiple brokers

[Thomas M. <tho...@ho...>]

Hi again,

Christian Sell wrote:
> 
> Hi,
> 
> > ojb.odmg.oql.OQLQueryImpl.execute() uses a PersistenceBroker (PB) in
> > Autocommit mode to perform a getCollectionByQuery(...).
> > Maybe it would be more clean to use a PB.beginTransaction(); ...
> > PBCommitTransaction() sequence here. But as far as I see there are
> > really no open Transactions on the db. Also no locks for update or such
> > things.
> >
> > A new PersistenceBroker transaction is only started during ODMG
> > TransactionImpl.commit()
> > (see ojb.odmg.ObjectEnvelopeTable.commit() )
> 
> Hmm. I am not sure that I like this statement. On the one hand it does
> indeed mean that you are running without transactions until the final
> commit. OTOH, you are dropping a major benefit of transactions, which is the
> concept of transaction isolation. For example, if I set the isolation level
> to "repeatable read",  I can be sure that none of the data I have read
> within a transaction can be changed by another transaction. When using
> "serializable", I am even protected from inserts into the answer set of any
> query I executed (of course, the DBMS uses locks to ensure isolation. That
> is why even reading data places locks). All this only counts until the end
> of the transaction, so running in autocommit mode makes isolation
> ineffective. I dont think this can be mandated.

I totally agree with you! But OJB can't rely on database specific lock
mechanisms (e.g. DB2 does not provide a reliable row level locking !).
Thus OJB runs its own LockManager for distributed transactions. See
http://objectbridge.sourceforge.net/system/lockmanager.html for details.
Of course it provides all relevant tx isolation levels from dirty reads
to serializable.


> > Yes that is a very good idea! Especially with our plans to build a JDO
> > compliant implementation.
> > I had a look at the JDO metadata DTD more than a half year ago. As far
> > as I remember there was nothing specified for O/R mappings then. But it
> > seems things have evolved a bit.
> 
> no, I wasn't saying that JDO specified anything with regard to mapping. It
> only mandates the generic persistence metadata, which looks loosely like
> this:
> 
> <jdo>
>   <package name="com.dada.dudu.sample">
>     <class name="Person" identity-type="application"
> objectid-class="com.dada.dudu.sample.PersonKey">
>       <field name="key" default-fetch-group="true" primary-key="true" />
>       <field name="birthday" default-fetch-group="true" />
>     </class>
>   </package>
> </jdo>
> 
> The mapping metadata has to be kept separately, but is not specified by JDO.
> 
> > We should rely as much as possible on standards as possible (provided
> > they fulfill our needs).
> 
> I would even drop the "provided" part. One should decide to go either 100%
> with the standard, or not care for it at all (except as inspiration)
> 
> > A similar point regarding standards:
> > There is an initiative of Carl Rosenberger (http://www.db4o.com) on a
> > standardized java api for oodms queries called SODA (simple object data
> > access) (http://www.soda.org).
> 
> this is what I read when following the above link:
> 
> "S.O.D.A. is a non-profit organization formed to provide ongoing support and
> stewardship
> for the Off-Leash dog exercising area at Marymoor Park in Redmond,
> Washington"
> 

Ehm, the right link is http://www.odbms.org ;-)

> > It is quite similar to the ojb.broker.query API. I'm thinking of
> > replacing the OJB query API with SODA as it's quite clean and a evolving
> > standard.
> >
> > What do you think?
> 
> I haven't looked into this, but from what you say it seems to overlap with
> the JDO query specification. In accordance with my previous statement about
> standards, I think one should decide whether to follow the standard and then
> direct all efforts towards fulfilling it first, before looking elsewhere.
> 

I don't see a conflict here. Of course we will have a 150% pure JDO
implementation.

For the ODMG implementation it works like follows:
ODMG OQL queries are parsed and translated into oj.broker.query.Query
objects.

Of course we can do something similar for the JDOQL.

My suggestion was to replace the propietary ojb.broker.query API with
the standardized SODA API.
I don't want to have something like JDOQL or OQL in the persistence
kernel!


regards,

Thomas