Thread: RE: [Objectbridge-developers] OJB Homepage, OQL
Brought to you by:
thma
Menu
▾
▴
objectbridge-developers
|
From: Dixon-Peugh, D. <Dav...@tp...> - 2001-01-23 14:15:45
|
Except of course, that QBE by itself (without extensions), is capable of everything that SQL does. (They are both languages for Relational Algebra after all.) On another topic. . . I'm thinking about finishing up the Transaction support soon, however I've got some questions about how we want to implement it. Perhaps you two could shed some light on what we should do. Basically, the issue is that if you use the raw JDBC driver, you cannot guarantee that two different connections will either both commit, or both abort. There are three ways around this that I can see: 1. Ignore it. 2. Force all JDBC connections to be the type that can participate in a distributed transaction. 3. Have OJB maintain its own Transaction log which can be used to issue compensating transactions, or complete transactions when starting up again. One is the easiest to do, but you don't have real transactional = integrity accross the database. Two will work, and it wouldn't be too hard to implement, but it limits=20 which JDBC drivers can be used. (I don't think Postgres or some of the other free databases have a distributed capable JDBC driver.) Three will also work, but it is obviously more work, and also leaves = open issues about ObJectBridge interacting with other more traditional = software. (The redo/undo of the log could overwrite something from the other App, = as we don't have exclusive control over it.) Any suggestions? Thanks, The other David. -----Original Message----- From: obj...@li... [mailto:obj...@li...]On Behalf = Of Mahler Thomas Sent: Tuesday, January 23, 2001 3:12 AM To: David W. Forslund Cc: objectbridge Subject: RE: [Objectbridge-developers] OJB Homepage, OQL > -----Urspr=FCngliche Nachricht----- > Von: obj...@li... > [mailto:obj...@li...]Im = Auftrag > von David W Forslund > Gesendet: Montag, 22. Januar 2001 20:41 > An: Thomas Mahler > Cc: objectbridge > Betreff: Re: [Objectbridge-developers] OJB Homepage, OQL > > > QBE, however, does not deal very well with query filters (like > inequality, similarity). There should be explicit support for that > (which would map directly to an OQL statement). > > Dave You are right of course. I was a bit lazy with my definition of QBE. In = fact I am thinking of an "QBE with extensions" that allows composition of = queries and query filters as in the SODA approach (http://www.egroups.com/files/oodb/query.html) or in the approach = mentioned in the COBRA whitepaper. > > Thomas Mahler writes: > > Thanks for all your comments regarding OQL and Query by Example = (QBE) > > facilities. > > > > IMHO it's the best solution to start with a QBE-facility and only = after > > that provide an OQL API. > > Starting with QBE has 2 advantages: > > - It will provide a useful extension to the PersistenceBroker, so = that > > it can be used even without the ODMG server > > - there are some working examples from other projects, that can be > > easily adopted to our needs > > > > Implementing OQL on top of such a facility will work licke = follows: > > - implement a parser that reads OQL-queries and generates query = trees. > > - provide a mapping from the abstract query trees to QBE query = objects. > > > > alternatively one could try to build a parser that directly = generates > > QBE query objects. > > > > I will have a look at all the projects you mentioned to find the = best > > possible start for the QBE facility. I liked the SODA approach > > (www.db4o.com), but I think they are not finished with their spec. > > > > I'll start with this asap. Right now I'm doing some performance = tuning > > deep inside the PersistenceBroker. I'm profiling OJB excution with = the > > java -Xrunhprof option which gives me some hints about execution = hot > > spots. I already identified some hot spots in the metadata = layer... > > > > regards, > > > > Thomas > > > > _______________________________________________ > > Objectbridge-developers mailing list > > Obj...@li... > > = http://lists.sourceforge.net/lists/listinfo/objectbridge-developers > > _______________________________________________ > Objectbridge-developers mailing list > Obj...@li... > http://lists.sourceforge.net/lists/listinfo/objectbridge-developers _______________________________________________ Objectbridge-developers mailing list Obj...@li... http://lists.sourceforge.net/lists/listinfo/objectbridge-developers |
|
From: Dixon-Peugh, D. <Dav...@tp...> - 2001-01-23 19:48:10
|
Right-o,
I'll look into number 2 then.
Of course your example brings in an interesting point. Right now all
the transactions are handled in the "ojb.server" section. But the
broker is responsible for storing the data.
This means the broker will need to be aware of the Transaction which
may mix the broker/server code together.
But, anyways, here is what I'm thinking now.
The first thing the broker does, is to check whether a transaction is
open or not.
If a transaction is open, then the operations that the broker
performs
fall under the current open transaction.
If a transaction is not open, then the broker does its operation
under
an implicit transaction.
This should be close to what CMT does in EJB, and certainly makes the
transactions
easier to implement.
David
-----Original Message-----
From: obj...@li...
[mailto:obj...@li...]On Behalf Of
Thomas Mahler
Sent: Tuesday, January 23, 2001 1:49 PM
To: 'objectbridge'
Subject: Re: [Objectbridge-developers] OJB Homepage, OQL
"Dixon-Peugh, David" wrote:
>
> Except of course, that QBE by itself (without extensions),
> is capable of everything that SQL does. (They are both
> languages for Relational Algebra after all.)
>
> On another topic. . .
>
> I'm thinking about finishing up the Transaction support soon,
> however I've got some questions about how we want to implement
> it. Perhaps you two could shed some light on what we should do.
>
> Basically, the issue is that if you use the raw JDBC driver, you
> cannot guarantee that two different connections will either both
> commit, or both abort.
>
> There are three ways around this that I can see:
> 1. Ignore it.
> 2. Force all JDBC connections to be the type that can
> participate in a distributed transaction.
> 3. Have OJB maintain its own Transaction log which can
> be used to issue compensating transactions, or complete
> transactions when starting up again.
>
> One is the easiest to do, but you don't have real transactional integrity
> accross the database.
>
> Two will work, and it wouldn't be too hard to implement, but it limits
> which JDBC drivers can be used. (I don't think Postgres or some of
> the other free databases have a distributed capable JDBC driver.)
>
> Three will also work, but it is obviously more work, and also leaves open
> issues about ObJectBridge interacting with other more traditional
software.
> (The redo/undo of the log could overwrite something from the other App, as
> we don't have exclusive control over it.)
>
Interesting point!
The PersistenceBroker (PB) is able to handle classes mapped to different
RDBMS. As of today there is no handling of such "inherently distributed"
in PB.
Even worse: the store() or delete() method don't declare exceptions to
allow detection of failed DB transactions. I introduced
beginTransaction(), commitTransaction() and commitTransaction() in the
PB interface, but they do nothing yet.
1. sounds good :-)
The question is: do we really have to support the feature of persistence
against distributed RDBMS?
It would be quite easy to change the repository.dtd to disallow
JDBCConnectionDescriptors on a per class basis but to enforce usage of a
one-for-all JDBC-connection.
This 30-second hack would finish the discussion for some time... (at
least until somebody asks "why can't I store my objects in different
databases?" )
2. this is my favourite solution. It would take some burden from our
shoulders through relying on the capabilities of the JDBC drivers and on
the JTA standard.
Take for example the SOAP developers: they don't deal with security
issues at all in the 1.1 spec, but simply tell you to take care for the
security of your transportlayer on your own.
I think this is a completely legitimate approach.
As a small team we have to concentrate our forces on the core things we
adress. And that is O/R mapping and not tx coordination between RDBMS.
So going this way we could offer: you can use PB to store Objects in
different database when the DB Vendors provide capable drivers. If the
drivers don't support distributed tx you have no proper tx support.
Sorry, but it's not our fault...
3. We will definitely need a Transaction log in the ODMG server
(something like the ojb.server.ObjectStateTable) which tracks the
modification state of each object touched by a transaction. But I don't
like the idea of keeping a log of the SQL operations as well. (why shall
WE do THEIR job ???)
Here is the design I have in mind:
a Transaction aware version of the ObjectStateTable::commit() method
could look like this:
/** perform commit on all tx-states */
public void commit()
{
try
{
broker.beginTransaction(); // broker is a private attribute
// of type PersistenceBroker
Iterator i = table.values().iterator();
while (i.hasNext())
{
ObjectModification mod = (ObjectModification)
i.next();
mod.getModificationState().commit(mod);
}
broker.commitTransaction();
}
catch (Throwable t)
{
// let broker rollback all performed operations
// this relies only the brokers capability
// to properly handle distributed tx against
// multiple RDBMS:
broker.abortTransaction();
// the ODMG tx must abort too, when updating one of the
// underlying rdbms failed:
this.rollback();
}
}
So as far as I see it, from an ojb.server point of view you can ignore
the underlying RDBMS completely by using the PersistenceBroker as a
blackbox which is responsible for proper 2 phase commits against all
RDBMS.
what do you think ?
regards,
the other Thomas :-)
_______________________________________________
Objectbridge-developers mailing list
Obj...@li...
http://lists.sourceforge.net/lists/listinfo/objectbridge-developers
|
|
From: Thomas M. <tho...@ho...> - 2001-01-23 21:15:35
|
"Dixon-Peugh, David" wrote:
>
> Right-o,
>
> I'll look into number 2 then.
>
> Of course your example brings in an interesting point. Right now all
> the transactions are handled in the "ojb.server" section. But the
> broker is responsible for storing the data.
>
> This means the broker will need to be aware of the Transaction which
> may mix the broker/server code together.
As I see it, there will be no mixing, we just have transaction on
distinct layers:
the ODMG server manages the transactions of all its clients. On
committing these transactions it opens a PersistenceBroker transaction
and now the PB has to manage the transaction against all the backend
RDBMS.
If something goes wrong during the PB commit, all RDBMS operations are
rolled back and the PB transaction fails, which causes the ODMG
transaction to fail also.
As I see it the ODMG server depends on the PB transaction. What the PB
has to do internally to manage all the JDBC transactions is of no
interest to the ODMG layer. The only thing important is: does the PB
compund transaction succeed or not? (the my commit() method below ).
But the PB transaction do not in any way depend on the ODMG
transactions.
SO we have three layers of transactions:
1. JDBC transaction against the backend RDBMS
2. the compound PersistenceBroker transaction, coordinating all tx from
1)
3. the ODMG transactions. they need a PB transaction on commiting
>
> But, anyways, here is what I'm thinking now.
>
> The first thing the broker does, is to check whether a transaction is
> open or not.
> If a transaction is open, then the operations that the broker
> performs
> fall under the current open transaction.
> If a transaction is not open, then the broker does its operation
> under
> an implicit transaction.
>
> This should be close to what CMT does in EJB, and certainly makes the
> transactions
> easier to implement.
>
> David
>
>
>
> -----Original Message-----
> From: obj...@li...
> [mailto:obj...@li...]On Behalf Of
> Thomas Mahler
> Sent: Tuesday, January 23, 2001 1:49 PM
> To: 'objectbridge'
> Subject: Re: [Objectbridge-developers] OJB Homepage, OQL
>
> "Dixon-Peugh, David" wrote:
> >
> > Except of course, that QBE by itself (without extensions),
> > is capable of everything that SQL does. (They are both
> > languages for Relational Algebra after all.)
> >
> > On another topic. . .
> >
> > I'm thinking about finishing up the Transaction support soon,
> > however I've got some questions about how we want to implement
> > it. Perhaps you two could shed some light on what we should do.
> >
> > Basically, the issue is that if you use the raw JDBC driver, you
> > cannot guarantee that two different connections will either both
> > commit, or both abort.
> >
> > There are three ways around this that I can see:
> > 1. Ignore it.
> > 2. Force all JDBC connections to be the type that can
> > participate in a distributed transaction.
> > 3. Have OJB maintain its own Transaction log which can
> > be used to issue compensating transactions, or complete
> > transactions when starting up again.
> >
> > One is the easiest to do, but you don't have real transactional integrity
> > accross the database.
> >
> > Two will work, and it wouldn't be too hard to implement, but it limits
> > which JDBC drivers can be used. (I don't think Postgres or some of
> > the other free databases have a distributed capable JDBC driver.)
> >
> > Three will also work, but it is obviously more work, and also leaves open
> > issues about ObJectBridge interacting with other more traditional
> software.
> > (The redo/undo of the log could overwrite something from the other App, as
> > we don't have exclusive control over it.)
> >
>
> Interesting point!
> The PersistenceBroker (PB) is able to handle classes mapped to different
> RDBMS. As of today there is no handling of such "inherently distributed"
> in PB.
> Even worse: the store() or delete() method don't declare exceptions to
> allow detection of failed DB transactions. I introduced
> beginTransaction(), commitTransaction() and commitTransaction() in the
> PB interface, but they do nothing yet.
>
> 1. sounds good :-)
> The question is: do we really have to support the feature of persistence
> against distributed RDBMS?
> It would be quite easy to change the repository.dtd to disallow
> JDBCConnectionDescriptors on a per class basis but to enforce usage of a
> one-for-all JDBC-connection.
> This 30-second hack would finish the discussion for some time... (at
> least until somebody asks "why can't I store my objects in different
> databases?" )
>
> 2. this is my favourite solution. It would take some burden from our
> shoulders through relying on the capabilities of the JDBC drivers and on
> the JTA standard.
> Take for example the SOAP developers: they don't deal with security
> issues at all in the 1.1 spec, but simply tell you to take care for the
> security of your transportlayer on your own.
> I think this is a completely legitimate approach.
> As a small team we have to concentrate our forces on the core things we
> adress. And that is O/R mapping and not tx coordination between RDBMS.
> So going this way we could offer: you can use PB to store Objects in
> different database when the DB Vendors provide capable drivers. If the
> drivers don't support distributed tx you have no proper tx support.
> Sorry, but it's not our fault...
>
> 3. We will definitely need a Transaction log in the ODMG server
> (something like the ojb.server.ObjectStateTable) which tracks the
> modification state of each object touched by a transaction. But I don't
> like the idea of keeping a log of the SQL operations as well. (why shall
> WE do THEIR job ???)
>
> Here is the design I have in mind:
>
> a Transaction aware version of the ObjectStateTable::commit() method
> could look like this:
>
> /** perform commit on all tx-states */
> public void commit()
> {
> try
> {
> broker.beginTransaction(); // broker is a private attribute
> // of type PersistenceBroker
> Iterator i = table.values().iterator();
> while (i.hasNext())
> {
> ObjectModification mod = (ObjectModification)
> i.next();
> mod.getModificationState().commit(mod);
> }
> broker.commitTransaction();
> }
> catch (Throwable t)
> {
> // let broker rollback all performed operations
> // this relies only the brokers capability
> // to properly handle distributed tx against
> // multiple RDBMS:
> broker.abortTransaction();
>
> // the ODMG tx must abort too, when updating one of the
> // underlying rdbms failed:
> this.rollback();
> }
> }
>
> So as far as I see it, from an ojb.server point of view you can ignore
> the underlying RDBMS completely by using the PersistenceBroker as a
> blackbox which is responsible for proper 2 phase commits against all
> RDBMS.
>
> what do you think ?
>
> regards,
> the other Thomas :-)
>
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> http://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> http://lists.sourceforge.net/lists/listinfo/objectbridge-developers
|
|
From: Dixon-Peugh, D. <Dav...@tp...> - 2001-01-23 21:31:59
|
I'm worried about code duplication then.
Basically, so far Transaction implementation has been done completely
from the ODMG side of things. It seems like we need to move the
implementation
of the transactions to the Broker side of things.
Once its on the broker side, then we can write the ODMG side as just a
simple wrapper.
BUT- The broker will need to have both explicit and implicit transactions
if the ODMG stuff is going to be a wrapper.
It almost makes sense to just go ahead and keep the ODMG transactions where
it is as the explicit transaction. And have the broker use it in building
an implicit one.
David.
-----Original Message-----
From: obj...@li...
[mailto:obj...@li...]On Behalf Of
Thomas Mahler
Sent: Tuesday, January 23, 2001 4:14 PM
To: Dixon-Peugh, David
Cc: 'objectbridge'
Subject: Re: [Objectbridge-developers] OJB Homepage, OQL
"Dixon-Peugh, David" wrote:
>
> Right-o,
>
> I'll look into number 2 then.
>
> Of course your example brings in an interesting point. Right now all
> the transactions are handled in the "ojb.server" section. But the
> broker is responsible for storing the data.
>
> This means the broker will need to be aware of the Transaction which
> may mix the broker/server code together.
As I see it, there will be no mixing, we just have transaction on
distinct layers:
the ODMG server manages the transactions of all its clients. On
committing these transactions it opens a PersistenceBroker transaction
and now the PB has to manage the transaction against all the backend
RDBMS.
If something goes wrong during the PB commit, all RDBMS operations are
rolled back and the PB transaction fails, which causes the ODMG
transaction to fail also.
As I see it the ODMG server depends on the PB transaction. What the PB
has to do internally to manage all the JDBC transactions is of no
interest to the ODMG layer. The only thing important is: does the PB
compund transaction succeed or not? (the my commit() method below ).
But the PB transaction do not in any way depend on the ODMG
transactions.
SO we have three layers of transactions:
1. JDBC transaction against the backend RDBMS
2. the compound PersistenceBroker transaction, coordinating all tx from
1)
3. the ODMG transactions. they need a PB transaction on commiting
>
> But, anyways, here is what I'm thinking now.
>
> The first thing the broker does, is to check whether a transaction is
> open or not.
> If a transaction is open, then the operations that the broker
> performs
> fall under the current open transaction.
> If a transaction is not open, then the broker does its operation
> under
> an implicit transaction.
>
> This should be close to what CMT does in EJB, and certainly makes the
> transactions
> easier to implement.
>
> David
>
>
>
> -----Original Message-----
> From: obj...@li...
> [mailto:obj...@li...]On Behalf Of
> Thomas Mahler
> Sent: Tuesday, January 23, 2001 1:49 PM
> To: 'objectbridge'
> Subject: Re: [Objectbridge-developers] OJB Homepage, OQL
>
> "Dixon-Peugh, David" wrote:
> >
> > Except of course, that QBE by itself (without extensions),
> > is capable of everything that SQL does. (They are both
> > languages for Relational Algebra after all.)
> >
> > On another topic. . .
> >
> > I'm thinking about finishing up the Transaction support soon,
> > however I've got some questions about how we want to implement
> > it. Perhaps you two could shed some light on what we should do.
> >
> > Basically, the issue is that if you use the raw JDBC driver, you
> > cannot guarantee that two different connections will either both
> > commit, or both abort.
> >
> > There are three ways around this that I can see:
> > 1. Ignore it.
> > 2. Force all JDBC connections to be the type that can
> > participate in a distributed transaction.
> > 3. Have OJB maintain its own Transaction log which can
> > be used to issue compensating transactions, or complete
> > transactions when starting up again.
> >
> > One is the easiest to do, but you don't have real transactional
integrity
> > accross the database.
> >
> > Two will work, and it wouldn't be too hard to implement, but it limits
> > which JDBC drivers can be used. (I don't think Postgres or some of
> > the other free databases have a distributed capable JDBC driver.)
> >
> > Three will also work, but it is obviously more work, and also leaves
open
> > issues about ObJectBridge interacting with other more traditional
> software.
> > (The redo/undo of the log could overwrite something from the other App,
as
> > we don't have exclusive control over it.)
> >
>
> Interesting point!
> The PersistenceBroker (PB) is able to handle classes mapped to different
> RDBMS. As of today there is no handling of such "inherently distributed"
> in PB.
> Even worse: the store() or delete() method don't declare exceptions to
> allow detection of failed DB transactions. I introduced
> beginTransaction(), commitTransaction() and commitTransaction() in the
> PB interface, but they do nothing yet.
>
> 1. sounds good :-)
> The question is: do we really have to support the feature of persistence
> against distributed RDBMS?
> It would be quite easy to change the repository.dtd to disallow
> JDBCConnectionDescriptors on a per class basis but to enforce usage of a
> one-for-all JDBC-connection.
> This 30-second hack would finish the discussion for some time... (at
> least until somebody asks "why can't I store my objects in different
> databases?" )
>
> 2. this is my favourite solution. It would take some burden from our
> shoulders through relying on the capabilities of the JDBC drivers and on
> the JTA standard.
> Take for example the SOAP developers: they don't deal with security
> issues at all in the 1.1 spec, but simply tell you to take care for the
> security of your transportlayer on your own.
> I think this is a completely legitimate approach.
> As a small team we have to concentrate our forces on the core things we
> adress. And that is O/R mapping and not tx coordination between RDBMS.
> So going this way we could offer: you can use PB to store Objects in
> different database when the DB Vendors provide capable drivers. If the
> drivers don't support distributed tx you have no proper tx support.
> Sorry, but it's not our fault...
>
> 3. We will definitely need a Transaction log in the ODMG server
> (something like the ojb.server.ObjectStateTable) which tracks the
> modification state of each object touched by a transaction. But I don't
> like the idea of keeping a log of the SQL operations as well. (why shall
> WE do THEIR job ???)
>
> Here is the design I have in mind:
>
> a Transaction aware version of the ObjectStateTable::commit() method
> could look like this:
>
> /** perform commit on all tx-states */
> public void commit()
> {
> try
> {
> broker.beginTransaction(); // broker is a private
attribute
> // of type PersistenceBroker
> Iterator i = table.values().iterator();
> while (i.hasNext())
> {
> ObjectModification mod = (ObjectModification)
> i.next();
> mod.getModificationState().commit(mod);
> }
> broker.commitTransaction();
> }
> catch (Throwable t)
> {
> // let broker rollback all performed operations
> // this relies only the brokers capability
> // to properly handle distributed tx against
> // multiple RDBMS:
> broker.abortTransaction();
>
> // the ODMG tx must abort too, when updating one of the
> // underlying rdbms failed:
> this.rollback();
> }
> }
>
> So as far as I see it, from an ojb.server point of view you can ignore
> the underlying RDBMS completely by using the PersistenceBroker as a
> blackbox which is responsible for proper 2 phase commits against all
> RDBMS.
>
> what do you think ?
>
> regards,
> the other Thomas :-)
>
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> http://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> http://lists.sourceforge.net/lists/listinfo/objectbridge-developers
_______________________________________________
Objectbridge-developers mailing list
Obj...@li...
http://lists.sourceforge.net/lists/listinfo/objectbridge-developers
|
|
From: <tho...@it...> - 2001-01-24 16:14:22
|
> -----Urspr=FCngliche Nachricht-----
> Von: obj...@li...
> [mailto:obj...@li...]Im Auftrag
> von Dixon-Peugh, David
> Gesendet: Dienstag, 23. Januar 2001 22:30
> An: 'Thomas Mahler'
> Cc: 'objectbridge'
> Betreff: RE: [Objectbridge-developers] OJB Homepage, OQL
>
>
> I'm worried about code duplication then.
>
> Basically, so far Transaction implementation has been done completely
> from the ODMG side of things. It seems like we need to move the
> implementation
> of the transactions to the Broker side of things.
I don't understand your argument.
Say we type A mapped to db oracle
and type B mapped to db mysql
then we could have the following ODMG session:
Implementation odmg =3D OJB.getInstance();
Database db =3D odmg.newDatabase();
db.open(databaseName, Database.OPEN_READ_WRITE);
Transaction tx =3D odmg.newTransaction();
tx.begin();
// 1. get OID's
A a =3D new A();
a.setId(89);
B b =3D new B();
b.setId(103);
String oid-a =3D odmg.getObjectId(a);
String oid-b =3D odmg.getObjectId(b);
// 2. lookup objects by OID
a =3D (A) db.lookup(oid-a);
b =3D (B) db.lookup(oid-b);
// 3. modify objects
a.setAttributeX("newValue"); // implicit call to markModified() !
b.setAttributeY("newValue"); // implicit call to markModified() !
// 4. commit
try
{
tx.commit();
}
catch (Throwable t)
{
tx.abort();
}
internally the commit results in a call to the transactions
ObjectStateTable::commit().
public void commit()
{
try
{
broker.beginTransaction(); // broker is a private attribu=
te
// of type PersistenceBroker
Iterator i =3D table.values().iterator();
while (i.hasNext())
{
ObjectModification mod =3D (ObjectModification)
i.next();
mod.getModificationState().commit(mod);
}
broker.commitTransaction();
}
catch (Throwable t)
{
broker.abortTransaction();
// the ODMG tx must abort too, when updating one of the
// underlying rdbms failed:
this.rollback();
}
}
The PB opens transaction for for the databases oracle and mysql and is
sequentially called to store the modified objects a and b.
say writing a to oracle succeeds. But writing of b to mysql fails.
The Persistencebroker does not need any knowledge about the stored object=
s
or the sequence in which they had been updated. It simply has to rollback
the transactions against oracle and mysql and then to throw an Exception.
The database maintain a transaction log and know which operations have to
been rolled back.
There will be no code doubling and all knowledge about object modificatio=
ns
will stay in the ODMG part (namely the transactions ObjectStateTable.
>
> Once its on the broker side, then we can write the ODMG side as just a
> simple wrapper.
>
> BUT- The broker will need to have both explicit and implicit transactio=
ns
> if the ODMG stuff is going to be a wrapper.
>
> It almost makes sense to just go ahead and keep the ODMG
> transactions where
> it is as the explicit transaction. And have the broker use it in build=
ing
> an implicit one.
>
> David.
>
>
> -----Original Message-----
> From: obj...@li...
> [mailto:obj...@li...]On Behalf O=
f
> Thomas Mahler
> Sent: Tuesday, January 23, 2001 4:14 PM
> To: Dixon-Peugh, David
> Cc: 'objectbridge'
> Subject: Re: [Objectbridge-developers] OJB Homepage, OQL
>
>
> "Dixon-Peugh, David" wrote:
> >
> > Right-o,
> >
> > I'll look into number 2 then.
> >
> > Of course your example brings in an interesting point. Right now all
> > the transactions are handled in the "ojb.server" section. But the
> > broker is responsible for storing the data.
> >
> > This means the broker will need to be aware of the Transaction which
> > may mix the broker/server code together.
>
> As I see it, there will be no mixing, we just have transaction on
> distinct layers:
> the ODMG server manages the transactions of all its clients. On
> committing these transactions it opens a PersistenceBroker transaction
> and now the PB has to manage the transaction against all the backend
> RDBMS.
> If something goes wrong during the PB commit, all RDBMS operations are
> rolled back and the PB transaction fails, which causes the ODMG
> transaction to fail also.
> As I see it the ODMG server depends on the PB transaction. What the PB
> has to do internally to manage all the JDBC transactions is of no
> interest to the ODMG layer. The only thing important is: does the PB
> compund transaction succeed or not? (the my commit() method below ).
> But the PB transaction do not in any way depend on the ODMG
> transactions.
>
> SO we have three layers of transactions:
> 1. JDBC transaction against the backend RDBMS
> 2. the compound PersistenceBroker transaction, coordinating all tx from
> 1)
> 3. the ODMG transactions. they need a PB transaction on commiting
>
> >
> > But, anyways, here is what I'm thinking now.
> >
> > The first thing the broker does, is to check whether a transaction is
> > open or not.
> > If a transaction is open, then the operations that the broker
> > performs
> > fall under the current open transaction.
> > If a transaction is not open, then the broker does its operat=
ion
> > under
> > an implicit transaction.
> >
> > This should be close to what CMT does in EJB, and certainly makes the
> > transactions
> > easier to implement.
> >
> > David
> >
> >
> >
> > -----Original Message-----
> > From: obj...@li...
> > [mailto:obj...@li...]On Behalf=
Of
> > Thomas Mahler
> > Sent: Tuesday, January 23, 2001 1:49 PM
> > To: 'objectbridge'
> > Subject: Re: [Objectbridge-developers] OJB Homepage, OQL
> >
> > "Dixon-Peugh, David" wrote:
> > >
> > > Except of course, that QBE by itself (without extensions),
> > > is capable of everything that SQL does. (They are both
> > > languages for Relational Algebra after all.)
> > >
> > > On another topic. . .
> > >
> > > I'm thinking about finishing up the Transaction support soon,
> > > however I've got some questions about how we want to implement
> > > it. Perhaps you two could shed some light on what we should do.
> > >
> > > Basically, the issue is that if you use the raw JDBC driver, you
> > > cannot guarantee that two different connections will either both
> > > commit, or both abort.
> > >
> > > There are three ways around this that I can see:
> > > 1. Ignore it.
> > > 2. Force all JDBC connections to be the type that can
> > > participate in a distributed transaction.
> > > 3. Have OJB maintain its own Transaction log which can
> > > be used to issue compensating transactions,
> or complete
> > > transactions when starting up again.
> > >
> > > One is the easiest to do, but you don't have real transactional
> integrity
> > > accross the database.
> > >
> > > Two will work, and it wouldn't be too hard to implement, but it lim=
its
> > > which JDBC drivers can be used. (I don't think Postgres or some of
> > > the other free databases have a distributed capable JDBC driver.)
> > >
> > > Three will also work, but it is obviously more work, and also leave=
s
> open
> > > issues about ObJectBridge interacting with other more traditional
> > software.
> > > (The redo/undo of the log could overwrite something from the
> other App,
> as
> > > we don't have exclusive control over it.)
> > >
> >
> > Interesting point!
> > The PersistenceBroker (PB) is able to handle classes mapped to differ=
ent
> > RDBMS. As of today there is no handling of such "inherently distribut=
ed"
> > in PB.
> > Even worse: the store() or delete() method don't declare exceptions t=
o
> > allow detection of failed DB transactions. I introduced
> > beginTransaction(), commitTransaction() and commitTransaction() in th=
e
> > PB interface, but they do nothing yet.
> >
> > 1. sounds good :-)
> > The question is: do we really have to support the feature of persiste=
nce
> > against distributed RDBMS?
> > It would be quite easy to change the repository.dtd to disallow
> > JDBCConnectionDescriptors on a per class basis but to enforce usage o=
f a
> > one-for-all JDBC-connection.
> > This 30-second hack would finish the discussion for some time... (at
> > least until somebody asks "why can't I store my objects in different
> > databases?" )
> >
> > 2. this is my favourite solution. It would take some burden from our
> > shoulders through relying on the capabilities of the JDBC drivers and=
on
> > the JTA standard.
> > Take for example the SOAP developers: they don't deal with security
> > issues at all in the 1.1 spec, but simply tell you to take care for t=
he
> > security of your transportlayer on your own.
> > I think this is a completely legitimate approach.
> > As a small team we have to concentrate our forces on the core things =
we
> > adress. And that is O/R mapping and not tx coordination between RDBMS.
> > So going this way we could offer: you can use PB to store Objects in
> > different database when the DB Vendors provide capable drivers. If th=
e
> > drivers don't support distributed tx you have no proper tx support.
> > Sorry, but it's not our fault...
> >
> > 3. We will definitely need a Transaction log in the ODMG server
> > (something like the ojb.server.ObjectStateTable) which tracks the
> > modification state of each object touched by a transaction. But I don=
't
> > like the idea of keeping a log of the SQL operations as well. (why sh=
all
> > WE do THEIR job ???)
> >
> > Here is the design I have in mind:
> >
> > a Transaction aware version of the ObjectStateTable::commit() method
> > could look like this:
> >
> > /** perform commit on all tx-states */
> > public void commit()
> > {
> > try
> > {
> > broker.beginTransaction(); // broker is a private
> attribute
> > // of type PersistenceBrok=
er
> > Iterator i =3D table.values().iterator();
> > while (i.hasNext())
> > {
> > ObjectModification mod =3D (ObjectModificatio=
n)
> > i.next();
> > mod.getModificationState().commit(mod);
> > }
> > broker.commitTransaction();
> > }
> > catch (Throwable t)
> > {
> > // let broker rollback all performed operations
> > // this relies only the brokers capability
> > // to properly handle distributed tx against
> > // multiple RDBMS:
> > broker.abortTransaction();
> >
> > // the ODMG tx must abort too, when updating one of t=
he
> > // underlying rdbms failed:
> > this.rollback();
> > }
> > }
> >
> > So as far as I see it, from an ojb.server point of view you can ignor=
e
> > the underlying RDBMS completely by using the PersistenceBroker as a
> > blackbox which is responsible for proper 2 phase commits against all
> > RDBMS.
> >
> > what do you think ?
> >
> > regards,
> > the other Thomas :-)
> >
> > _______________________________________________
> > Objectbridge-developers mailing list
> > Obj...@li...
> > http://lists.sourceforge.net/lists/listinfo/objectbridge-developers
> >
> > _______________________________________________
> > Objectbridge-developers mailing list
> > Obj...@li...
> > http://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> http://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> http://lists.sourceforge.net/lists/listinfo/objectbridge-developers
|
|
From: David F. <dw...@la...> - 2001-01-23 15:01:20
|
At 09:13 AM 1/23/2001 -0500, Dixon-Peugh, David wrote: >Except of course, that QBE by itself (without extensions), >is capable of everything that SQL does. (They are both >languages for Relational Algebra after all.) I agree that QBE is very powerful, but how does one do the equivalent of=20 "LIKE" with QBE without extensions? Or the concept of OR's? I'm quite interested in this. Dave >On another topic. . . > >I'm thinking about finishing up the Transaction support soon, >however I've got some questions about how we want to implement >it. Perhaps you two could shed some light on what we should do. > >Basically, the issue is that if you use the raw JDBC driver, you >cannot guarantee that two different connections will either both >commit, or both abort. > >There are three ways around this that I can see: > 1. Ignore it. > 2. Force all JDBC connections to be the type that can > participate in a distributed transaction. > 3. Have OJB maintain its own Transaction log which can > be used to issue compensating transactions, or complete > transactions when starting up again. > >One is the easiest to do, but you don't have real transactional integrity >accross the database. > >Two will work, and it wouldn't be too hard to implement, but it limits >which JDBC drivers can be used. (I don't think Postgres or some of >the other free databases have a distributed capable JDBC driver.) > >Three will also work, but it is obviously more work, and also leaves open >issues about ObJectBridge interacting with other more traditional software. >(The redo/undo of the log could overwrite something from the other App, as >we don't have exclusive control over it.) > >Any suggestions? > >Thanks, > >The other David. > >-----Original Message----- >From: obj...@li... >[mailto:obj...@li...]On Behalf Of >Mahler Thomas >Sent: Tuesday, January 23, 2001 3:12 AM >To: David W. Forslund >Cc: objectbridge >Subject: RE: [Objectbridge-developers] OJB Homepage, OQL > > > > > > -----Urspr=FCngliche Nachricht----- > > Von: obj...@li... > > [mailto:obj...@li...]Im Auftrag > > von David W Forslund > > Gesendet: Montag, 22. Januar 2001 20:41 > > An: Thomas Mahler > > Cc: objectbridge > > Betreff: Re: [Objectbridge-developers] OJB Homepage, OQL > > > > > > QBE, however, does not deal very well with query filters (like > > inequality, similarity). There should be explicit support for that > > (which would map directly to an OQL statement). > > > > Dave > >You are right of course. I was a bit lazy with my definition of QBE. In= fact >I am thinking of an "QBE with extensions" that allows composition of= queries >and query filters as in the SODA approach >(http://www.egroups.com/files/oodb/query.html) or in the approach mentioned >in the COBRA whitepaper. > > > > > > Thomas Mahler writes: > > > Thanks for all your comments regarding OQL and Query by Example (QBE) > > > facilities. > > > > > > IMHO it's the best solution to start with a QBE-facility and only= after > > > that provide an OQL API. > > > Starting with QBE has 2 advantages: > > > - It will provide a useful extension to the PersistenceBroker, so= that > > > it can be used even without the ODMG server > > > - there are some working examples from other projects, that can be > > > easily adopted to our needs > > > > > > Implementing OQL on top of such a facility will work licke follows: > > > - implement a parser that reads OQL-queries and generates query= trees. > > > - provide a mapping from the abstract query trees to QBE query= objects. > > > > > > alternatively one could try to build a parser that directly generates > > > QBE query objects. > > > > > > I will have a look at all the projects you mentioned to find the best > > > possible start for the QBE facility. I liked the SODA approach > > > (www.db4o.com), but I think they are not finished with their spec. > > > > > > I'll start with this asap. Right now I'm doing some performance= tuning > > > deep inside the PersistenceBroker. I'm profiling OJB excution with= the > > > java -Xrunhprof option which gives me some hints about execution hot > > > spots. I already identified some hot spots in the metadata layer... > > > > > > regards, > > > > > > Thomas > > > > > > _______________________________________________ > > > Objectbridge-developers mailing list > > > Obj...@li... > > > http://lists.sourceforge.net/lists/listinfo/objectbridge-developers > > > > _______________________________________________ > > Objectbridge-developers mailing list > > Obj...@li... > > http://lists.sourceforge.net/lists/listinfo/objectbridge-developers > > >_______________________________________________ >Objectbridge-developers mailing list >Obj...@li... >http://lists.sourceforge.net/lists/listinfo/objectbridge-developers David W. Forslund dw...@la... Computer and Computational Sciences http://www.acl.lanl.gov/~dwf Los Alamos National Laboratory Los Alamos, NM 87545 505-665-1907 FAX: 505-665-4939 |
|
From: Thomas M. <tho...@ho...> - 2001-01-23 18:50:29
|
"Dixon-Peugh, David" wrote:
>
> Except of course, that QBE by itself (without extensions),
> is capable of everything that SQL does. (They are both
> languages for Relational Algebra after all.)
>
> On another topic. . .
>
> I'm thinking about finishing up the Transaction support soon,
> however I've got some questions about how we want to implement
> it. Perhaps you two could shed some light on what we should do.
>
> Basically, the issue is that if you use the raw JDBC driver, you
> cannot guarantee that two different connections will either both
> commit, or both abort.
>
> There are three ways around this that I can see:
> 1. Ignore it.
> 2. Force all JDBC connections to be the type that can
> participate in a distributed transaction.
> 3. Have OJB maintain its own Transaction log which can
> be used to issue compensating transactions, or complete
> transactions when starting up again.
>
> One is the easiest to do, but you don't have real transactional integrity
> accross the database.
>
> Two will work, and it wouldn't be too hard to implement, but it limits
> which JDBC drivers can be used. (I don't think Postgres or some of
> the other free databases have a distributed capable JDBC driver.)
>
> Three will also work, but it is obviously more work, and also leaves open
> issues about ObJectBridge interacting with other more traditional software.
> (The redo/undo of the log could overwrite something from the other App, as
> we don't have exclusive control over it.)
>
Interesting point!
The PersistenceBroker (PB) is able to handle classes mapped to different
RDBMS. As of today there is no handling of such "inherently distributed"
in PB.
Even worse: the store() or delete() method don't declare exceptions to
allow detection of failed DB transactions. I introduced
beginTransaction(), commitTransaction() and commitTransaction() in the
PB interface, but they do nothing yet.
1. sounds good :-)
The question is: do we really have to support the feature of persistence
against distributed RDBMS?
It would be quite easy to change the repository.dtd to disallow
JDBCConnectionDescriptors on a per class basis but to enforce usage of a
one-for-all JDBC-connection.
This 30-second hack would finish the discussion for some time... (at
least until somebody asks "why can't I store my objects in different
databases?" )
2. this is my favourite solution. It would take some burden from our
shoulders through relying on the capabilities of the JDBC drivers and on
the JTA standard.
Take for example the SOAP developers: they don't deal with security
issues at all in the 1.1 spec, but simply tell you to take care for the
security of your transportlayer on your own.
I think this is a completely legitimate approach.
As a small team we have to concentrate our forces on the core things we
adress. And that is O/R mapping and not tx coordination between RDBMS.
So going this way we could offer: you can use PB to store Objects in
different database when the DB Vendors provide capable drivers. If the
drivers don't support distributed tx you have no proper tx support.
Sorry, but it's not our fault...
3. We will definitely need a Transaction log in the ODMG server
(something like the ojb.server.ObjectStateTable) which tracks the
modification state of each object touched by a transaction. But I don't
like the idea of keeping a log of the SQL operations as well. (why shall
WE do THEIR job ???)
Here is the design I have in mind:
a Transaction aware version of the ObjectStateTable::commit() method
could look like this:
/** perform commit on all tx-states */
public void commit()
{
try
{
broker.beginTransaction(); // broker is a private attribute
// of type PersistenceBroker
Iterator i = table.values().iterator();
while (i.hasNext())
{
ObjectModification mod = (ObjectModification) i.next();
mod.getModificationState().commit(mod);
}
broker.commitTransaction();
}
catch (Throwable t)
{
// let broker rollback all performed operations
// this relies only the brokers capability
// to properly handle distributed tx against
// multiple RDBMS:
broker.abortTransaction();
// the ODMG tx must abort too, when updating one of the
// underlying rdbms failed:
this.rollback();
}
}
So as far as I see it, from an ojb.server point of view you can ignore
the underlying RDBMS completely by using the PersistenceBroker as a
blackbox which is responsible for proper 2 phase commits against all
RDBMS.
what do you think ?
regards,
the other Thomas :-)
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X