You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-user@db.apache.org by Laurie Harper <zo...@holoweb.net> on 2002/11/28 23:49:16 UTC
Re: Use of ODMG transactions
Thomas Mahler wrote:
> > 1) Sould the above work?
> no!
Was afraid of that :( Thanks for the clarification.
> The OJB OTM layer might be regarded as such a layer. But it could also
> be regarded as yet another O/R Api that should be encapsulated by yet
> another abstraction ;-)
I guess I'm thinking about a couple of different types of abstraction.
Firstly, there's abstracting the ODMG implementation so I could switch
in another one with minimal code change. That's clearly easy.
Next would be abstracting the persistence API in use, so I could switch
between ODMG, JDO or what have you and changes would be isolated to my
persistence abstraction layer (and perhaps the business objects) without
affecting client code. That seem harder, but could probably be done.
Ideally, there'd be a high enough level abstraction on top of all that
so that client code didn't need to know if it was dealing with a
persistent object or a non-persistent object. At this point, you may as
well just adopt EJB or something ;-)
I think there are middle grounds for what's worth doing vs. how much
flexibility it leaves you, but haven't played with or thought about it
enough to see where the borders are.
I need Martin's book! :-)
L.
Re: Use of ODMG transactions
Posted by Laurie Harper <zo...@holoweb.net>.
J. Russell Smyth wrote:
> Biggest limitation is the SCSL - which means no commercial use without
> paying the Sun tax, and there is a possibility of becoming "tainted" so
> that any work you do for an open source project that bears a resemblence
> to the sun code could become a legal battle over patents
>
> I cannot find a concrete discussion of the last point, but it is
> something that I am unsure enough about that I refuse to accept the SCSL
> - I will not give away my right to develop OSS!
OK, that's a good point! I didn't bother reading the full license when I
downloaded the software so I didn't realise it was one of those...
L.
Re: Use of ODMG transactions
Posted by "J. Russell Smyth" <dr...@cox.net>.
> But there are some more subtle gotchya's -- like the way ODMG requires
> you to lock an object to a transaction before you modify it but JDO
> doesn't. I'm sure there are others :-)
and the way JDO requires you to modify your object model and ODMG does
not ;-)
>
> > The JDORI + OjbStore Solution should be a as complete as the Default RI
> > 1.0 from SUN.
> >
> > The OjbStore simply replaces the default FoStore to provide an O/R
> > backend instead of an file based backend.
I have not looked at the JDORI (due to my refusal to accept the SCSL)
but if it is anything like most other Sun RI's, then it will be mostly
incomplete and flawed... Anyone here ever play with the J2EE 1.2 RI?
> So the obvious question is: what benefits will OJB's native JDO
> implementation provide when it's ready? Or, put another way, what are
> the limitations of the JDORI + OJB approach?
Biggest limitation is the SCSL - which means no commercial use without
paying the Sun tax, and there is a possibility of becoming "tainted" so
that any work you do for an open source project that bears a resemblence
to the sun code could become a legal battle over patents
I cannot find a concrete discussion of the last point, but it is
something that I am unsure enough about that I refuse to accept the SCSL
- I will not give away my right to develop OSS!
Russell
Re: Use of ODMG transactions
Posted by Thomas Mahler <th...@apache.org>.
Hi,
Hanasaki JiJi wrote:
> How are situations handled when a database automatically raises a row
> lock to table or page level?
>
I'm not sure which layer you have in mind with your question.
The OJB ODMG layer? or the proprietary tx wrapper I was discussing with
Laurie in this thread?
For the ODMG layer it works as follows:
OJB does not use any row-level locking. thus there cannot be any lock
escalations to page- or table-level.
OJB ODMG implements its own lockmanager that provides pessimistic
locking on a per object basis. This allows to keep things flexible for
very different locking strategies.
And it also guarantees platform neutrality of our ODMG layer.
cheers,
Thomas
> Thomas Mahler wrote:
>
>> Hi again,
>>
>> Laurie Harper wrote:
>>
>>>
>>> To write a plugin; I meant it was a lot of work to write the initial
>>> query abstraction. Or is that a mis-conception on my part?
>>
>>
>>
>> The query abstraction was the most simple thing: we just consented to
>> use the OJB query API! It's really easy to translate Toplink
>> Expression builder queries to OJB queries and vice versa.
>>
>>>> ODMG and JDO are *very* similar from an API point of view. The main
>>>> difference I see is the Query language.
>>>> So it won't be a big deal to start with ODMG today and to switch to a
>>>> JDO implementation later.
>>>
>>>
>>>
>>>
>>>
>>> But there are some more subtle gotchya's -- like the way ODMG
>>> requires you to lock an object to a transaction before you modify it
>>> but JDO doesn't. I'm sure there are others :-)
>>
>>
>>
>> sure! Our transaction wrapper relies on explicit locking.
>>
>>>> The JDORI + OjbStore Solution should be a as complete as the Default RI
>>>> 1.0 from SUN.
>>>>
>>>> The OjbStore simply replaces the default FoStore to provide an O/R
>>>> backend instead of an file based backend.
>>>
>>>
>>>
>>>
>>>
>>> So the obvious question is: what benefits will OJB's native JDO
>>> implementation provide when it's ready?
>>
>>
>>
>> Being an optimist, I assume that SUNs JDO RI does not contain any bugs
>> and is fully compliant to the spec.
>> Thus the OJB native implementation we have no *functional* benefits.
>> But I see several non-functional benefits:
>> - It will be an *OSS* JDO implementation
>> - thus the community will be allowed to modifiy and reuse the code
>> without getting trapped in copyright and license issues.
>> - thus it's much easy to fix bugs and implement future improvements.
>> - It can be optimized for the OJB PB (the JDORI seems to be optimized
>> for the special features of FoStore and does a several things like
>> attribute fetching that do not make much sense with a PB backend)
>> - Having an abstract Object Transaction Management layer does also
>> have several benefits. E.G. Users that don't want to stick to ODMG or
>> JDO could use it (or write derivates) as a persistence API.
>>
>>> Or, put another way, what are the limitations of the JDORI + OJB
>>> approach?
>>>
>>>> But I did not have the time to run the JDORI testsuite or the JDO TCK
>>>> against this solution.
>>>> I assume there are still some bugs or shortcomings...
>>>
>>>
>>>
>>>
>>>
>>> I had a look at doing this but got a bit entangled and then had to
>>> switch to something else. If I get the chance to try again I assume
>>> you'll be interested in the results ;-)
>>
>>
>>
>> sure!
>>
>> cheers,
>> Thomas
>>
>>> L.
>>>
>>>
>>> --
>>> To unsubscribe, e-mail:
>>> <ma...@jakarta.apache.org>
>>> For additional commands, e-mail:
>>> <ma...@jakarta.apache.org>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>> --
>> To unsubscribe, e-mail:
>> <ma...@jakarta.apache.org>
>> For additional commands, e-mail:
>> <ma...@jakarta.apache.org>
>>
>
Re: Use of ODMG transactions
Posted by Hanasaki JiJi <ha...@hanaden.com>.
How are situations handled when a database automatically raises a row
lock to table or page level?
Thomas Mahler wrote:
> Hi again,
>
> Laurie Harper wrote:
>
>>
>> To write a plugin; I meant it was a lot of work to write the initial
>> query abstraction. Or is that a mis-conception on my part?
>
>
> The query abstraction was the most simple thing: we just consented to
> use the OJB query API! It's really easy to translate Toplink Expression
> builder queries to OJB queries and vice versa.
>
>>> ODMG and JDO are *very* similar from an API point of view. The main
>>> difference I see is the Query language.
>>> So it won't be a big deal to start with ODMG today and to switch to a
>>> JDO implementation later.
>>
>>
>>
>>
>> But there are some more subtle gotchya's -- like the way ODMG requires
>> you to lock an object to a transaction before you modify it but JDO
>> doesn't. I'm sure there are others :-)
>
>
> sure! Our transaction wrapper relies on explicit locking.
>
>>> The JDORI + OjbStore Solution should be a as complete as the Default RI
>>> 1.0 from SUN.
>>>
>>> The OjbStore simply replaces the default FoStore to provide an O/R
>>> backend instead of an file based backend.
>>
>>
>>
>>
>> So the obvious question is: what benefits will OJB's native JDO
>> implementation provide when it's ready?
>
>
> Being an optimist, I assume that SUNs JDO RI does not contain any bugs
> and is fully compliant to the spec.
> Thus the OJB native implementation we have no *functional* benefits.
> But I see several non-functional benefits:
> - It will be an *OSS* JDO implementation
> - thus the community will be allowed to modifiy and reuse the code
> without getting trapped in copyright and license issues.
> - thus it's much easy to fix bugs and implement future improvements.
> - It can be optimized for the OJB PB (the JDORI seems to be optimized
> for the special features of FoStore and does a several things like
> attribute fetching that do not make much sense with a PB backend)
> - Having an abstract Object Transaction Management layer does also
> have several benefits. E.G. Users that don't want to stick to ODMG or
> JDO could use it (or write derivates) as a persistence API.
>
>> Or, put another way, what are the limitations of the JDORI + OJB
>> approach?
>>
>>> But I did not have the time to run the JDORI testsuite or the JDO TCK
>>> against this solution.
>>> I assume there are still some bugs or shortcomings...
>>
>>
>>
>>
>> I had a look at doing this but got a bit entangled and then had to
>> switch to something else. If I get the chance to try again I assume
>> you'll be interested in the results ;-)
>
>
> sure!
>
> cheers,
> Thomas
>
>> L.
>>
>>
>> --
>> To unsubscribe, e-mail:
>> <ma...@jakarta.apache.org>
>> For additional commands, e-mail:
>> <ma...@jakarta.apache.org>
>>
>>
>>
>>
>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
=================================================================
= Management is doing things right; leadership is doing the =
= right things. - Peter Drucker =
=_______________________________________________________________=
= http://www.sun.com/service/sunps/jdc/javacenter.pdf =
= www.sun.com | www.javasoft.com | http://wwws.sun.com/sunone =
=================================================================
Re: Use of ODMG transactions
Posted by Thomas Mahler <th...@apache.org>.
Hi again,
Laurie Harper wrote:
>
> To write a plugin; I meant it was a lot of work to write the initial
> query abstraction. Or is that a mis-conception on my part?
The query abstraction was the most simple thing: we just consented to
use the OJB query API! It's really easy to translate Toplink Expression
builder queries to OJB queries and vice versa.
>> ODMG and JDO are *very* similar from an API point of view. The main
>> difference I see is the Query language.
>> So it won't be a big deal to start with ODMG today and to switch to a
>> JDO implementation later.
>
>
>
> But there are some more subtle gotchya's -- like the way ODMG requires
> you to lock an object to a transaction before you modify it but JDO
> doesn't. I'm sure there are others :-)
sure! Our transaction wrapper relies on explicit locking.
>> The JDORI + OjbStore Solution should be a as complete as the Default RI
>> 1.0 from SUN.
>>
>> The OjbStore simply replaces the default FoStore to provide an O/R
>> backend instead of an file based backend.
>
>
>
> So the obvious question is: what benefits will OJB's native JDO
> implementation provide when it's ready?
Being an optimist, I assume that SUNs JDO RI does not contain any bugs
and is fully compliant to the spec.
Thus the OJB native implementation we have no *functional* benefits.
But I see several non-functional benefits:
- It will be an *OSS* JDO implementation
- thus the community will be allowed to modifiy and reuse the code
without getting trapped in copyright and license issues.
- thus it's much easy to fix bugs and implement future improvements.
- It can be optimized for the OJB PB (the JDORI seems to be optimized
for the special features of FoStore and does a several things like
attribute fetching that do not make much sense with a PB backend)
- Having an abstract Object Transaction Management layer does also
have several benefits. E.G. Users that don't want to stick to ODMG or
JDO could use it (or write derivates) as a persistence API.
> Or, put another way, what are
> the limitations of the JDORI + OJB approach?
>
>> But I did not have the time to run the JDORI testsuite or the JDO TCK
>> against this solution.
>> I assume there are still some bugs or shortcomings...
>
>
>
> I had a look at doing this but got a bit entangled and then had to
> switch to something else. If I get the chance to try again I assume
> you'll be interested in the results ;-)
sure!
cheers,
Thomas
> L.
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
Re: Use of ODMG transactions
Posted by Laurie Harper <zo...@holoweb.net>.
Thomas Mahler wrote:
> >> All you have to do to plug in a concrete persistence layer is to
> > [...]
> > Easy once you've already got the framework and just need to write the
> > glue, though, right?
> It was only a few days work.
To write a plugin; I meant it was a lot of work to write the initial
query abstraction. Or is that a mis-conception on my part?
> ODMG and JDO are *very* similar from an API point of view. The main
> difference I see is the Query language.
> So it won't be a big deal to start with ODMG today and to switch to a
> JDO implementation later.
But there are some more subtle gotchya's -- like the way ODMG requires
you to lock an object to a transaction before you modify it but JDO
doesn't. I'm sure there are others :-)
> The JDORI + OjbStore Solution should be a as complete as the Default RI
> 1.0 from SUN.
>
> The OjbStore simply replaces the default FoStore to provide an O/R
> backend instead of an file based backend.
So the obvious question is: what benefits will OJB's native JDO
implementation provide when it's ready? Or, put another way, what are
the limitations of the JDORI + OJB approach?
> But I did not have the time to run the JDORI testsuite or the JDO TCK
> against this solution.
> I assume there are still some bugs or shortcomings...
I had a look at doing this but got a bit entangled and then had to
switch to something else. If I get the chance to try again I assume
you'll be interested in the results ;-)
L.
Re: Use of ODMG transactions
Posted by Thomas Mahler <th...@apache.org>.
Hi again Laurie,
Laurie Harper wrote:
> Thomas Mahler wrote:
>
>> In fact we are doing this in my companies business frameworks. We
>> support TopLink and OJB as strategic persistence layers. (There is also
>> a LDAP implementation)
>
>
>
> Proprietary or based on another persistence framework? I started out
> wanting to use LDAP but switched to a database because I couldn't find
> any working LDAP mapping frameworks...
>
It's a closed source inhouse product. So I can't shair sources...
>> A customer may choose to use either OJB or TopLink.
>>
>> We provide a very thin abstraction layer above the persistence layers.
>> 1. There is a Session interface used to connect to the backend datastore
>> with username and password.
>> 2. there is a Transaction (or unit-of-work) interface with methods for
>> beginning, commiting and aborting transactions, methods to register
>> objects to the transaction and a methods to perform Queries.
>
>
>
> So that would be the equivalent of ODMG's lock()?
>
exactly. our tx.register(instance) is delegated to an ODMG
tx.lock(instance);
>> 3. A query API with an AST representation of queries. (We are using the
>> OJB Query package here). A good choice could be to use SODA
>> (http://www.odbms.org) as abstract query syntax!
>
>
>
> This strikes me as being where the work is here; it's sort of painful to
> have to write a query API to abstract away competing standards :-)
>
>> All you have to do to plug in a concrete persistence layer is to
>> 1. provide a SessionImpl,
>> 2. provide a TransactionImpl
>> 3. provide a Translator that translates the AST queries representation
>> into the query representation of the concrete persistence layer.
>> Building this translator for TopLink was *very* easy, as the TL
>> expressionbuilder is quite similar to OJB queries.
>
>
>
> Easy once you've already got the framework and just need to write the
> glue, though, right?
It was only a few days work.
>> Our approach is minimalistic, but did work even for large scale
>> applications!
>
>
>
> From another posting I guess you can't share any of this?
Yes, it's closed source.
> To be honest,
> I'd rather learn enough about ODMG and JDO to pick one and avoid the
> need to write the query abstraction component of the framework you've
> described.
ODMG and JDO are *very* similar from an API point of view. The main
difference I see is the Query language.
So it won't be a big deal to start with ODMG today and to switch to a
JDO implementation later.
> Do I understand correctly that the JDO reference implementation provider
> you posted last week means that I could adopt JDO with ODMG now? Or is
> JJDO RI + OJB still a limitted feature set?
The JDORI + OjbStore Solution should be a as complete as the Default RI
1.0 from SUN.
The OjbStore simply replaces the default FoStore to provide an O/R
backend instead of an file based backend.
But I did not have the time to run the JDORI testsuite or the JDO TCK
against this solution.
I assume there are still some bugs or shortcomings...
cheers,
Thomas
> L.
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
Re: Use of ODMG transactions
Posted by Laurie Harper <zo...@holoweb.net>.
Thomas Mahler wrote:
> In fact we are doing this in my companies business frameworks. We
> support TopLink and OJB as strategic persistence layers. (There is also
> a LDAP implementation)
Proprietary or based on another persistence framework? I started out
wanting to use LDAP but switched to a database because I couldn't find
any working LDAP mapping frameworks...
> A customer may choose to use either OJB or TopLink.
>
> We provide a very thin abstraction layer above the persistence layers.
> 1. There is a Session interface used to connect to the backend datastore
> with username and password.
> 2. there is a Transaction (or unit-of-work) interface with methods for
> beginning, commiting and aborting transactions, methods to register
> objects to the transaction and a methods to perform Queries.
So that would be the equivalent of ODMG's lock()?
> 3. A query API with an AST representation of queries. (We are using the
> OJB Query package here). A good choice could be to use SODA
> (http://www.odbms.org) as abstract query syntax!
This strikes me as being where the work is here; it's sort of painful to
have to write a query API to abstract away competing standards :-)
> All you have to do to plug in a concrete persistence layer is to
> 1. provide a SessionImpl,
> 2. provide a TransactionImpl
> 3. provide a Translator that translates the AST queries representation
> into the query representation of the concrete persistence layer.
> Building this translator for TopLink was *very* easy, as the TL
> expressionbuilder is quite similar to OJB queries.
Easy once you've already got the framework and just need to write the
glue, though, right?
> Our approach is minimalistic, but did work even for large scale
> applications!
From another posting I guess you can't share any of this? To be honest,
I'd rather learn enough about ODMG and JDO to pick one and avoid the
need to write the query abstraction component of the framework you've
described.
Do I understand correctly that the JDO reference implementation provider
you posted last week means that I could adopt JDO with ODMG now? Or is
JJDO RI + OJB still a limitted feature set?
L.
Re: Use of ODMG transactions
Posted by Thomas Mahler <th...@apache.org>.
Hi again Laurie,
<snip>
> I guess I'm thinking about a couple of different types of abstraction.
> Firstly, there's abstracting the ODMG implementation so I could switch
> in another one with minimal code change. That's clearly easy.
+1
> Next would be abstracting the persistence API in use, so I could switch
> between ODMG, JDO or what have you and changes would be isolated to my
> persistence abstraction layer (and perhaps the business objects) without
> affecting client code. That seem harder, but could probably be done.
>
In fact we are doing this in my companies business frameworks. We
support TopLink and OJB as strategic persistence layers. (There is also
a LDAP implementation)
A customer may choose to use either OJB or TopLink.
We provide a very thin abstraction layer above the persistence layers.
1. There is a Session interface used to connect to the backend datastore
with username and password.
2. there is a Transaction (or unit-of-work) interface with methods for
beginning, commiting and aborting transactions, methods to register
objects to the transaction and a methods to perform Queries.
3. A query API with an AST representation of queries. (We are using the
OJB Query package here). A good choice could be to use SODA
(http://www.odbms.org) as abstract query syntax!
All you have to do to plug in a concrete persistence layer is to
1. provide a SessionImpl,
2. provide a TransactionImpl
3. provide a Translator that translates the AST queries representation
into the query representation of the concrete persistence layer.
Building this translator for TopLink was *very* easy, as the TL
expressionbuilder is quite similar to OJB queries.
> Ideally, there'd be a high enough level abstraction on top of all that
> so that client code didn't need to know if it was dealing with a
> persistent object or a non-persistent object. At this point, you may as
> well just adopt EJB or something ;-)
>
> I think there are middle grounds for what's worth doing vs. how much
> flexibility it leaves you, but haven't played with or thought about it
> enough to see where the borders are.
>
Our approach is minimalistic, but did work even for large scale
applications!
cheers,
Thomas
> I need Martin's book! :-)
>
> L.
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>