Hi again Michael,

Michael Duffy wrote:
Thanks to both Thomas and Armin for their replies on
this thread.

Speaking for myself, I'm nervous about using OJB on my
current project, too, but I don't think the source is
entirely OJB.  A big part of it is fear of what I
DON'T know.  I very much liked the idea of using a
tool, developed by folks more expert than me.  I know
enought about JDBC to be able to do CRUD operations
and simple transactions, but the idea of having a
layer to abstract all that out of business objects was
appealing.

I heard Martin Fowler talk a few months ago. He
mentioned using JAXOR as an O/R mapping tool. When I
looked into it, I found NO documentation whatsoever.


Google quickly turned up OJB as an alternative. I
liked it right away, because it had more documentation
than JAXOR, it the cachet of being a Jakarta project,
and the stuff that I did actually worked. Now I've
got a tree of four tables linked with m:n
associations, all working in JUnit tests.


All that's well and good, but now I'm nervous about
that learning curve and what I'm ignorant of.  I've
done everything with the PersistenceBroker API because
it was easy to follow in the docs.  But now I'm
thinking that I should really be doing all of this
using ODMG API instead.  More learning, with a
deadline approaching.

choosing the actual OJB API is an important decision.


Why do you think you should use ODMG ? Do you really need Object level transactions?

If you plan to build your own persistence Manager layer with Data Access Objects (DAO) (and possibly DTOs) you could be better of with the PB API.

The PB API gives you maximum flexibility and nicely fits into J2EE based programming models.

The ODMG API specification was designed as a two-tier rich client API.



Here's a fundamental question:


RDBMS developers have put a lot of effort into
maintaining referential integrity, managing
transactions, etc.  It seems to me that OJB is taking
over a lot of that stuff.  When I created my tables, I
didn't add foreign key constraints.  I left all that
to OJB.  The ODMG API will handle true transactions
and object/row locking.

The OJB/ODMG does have pessimistic object level locking. But it does not provide DB row level locking!



But what if OJB isn't the only path into the database? A DBA might balk at leaving all those things that the RDBMS would handle to OJB. Is it possible still leave foreign key constraints in the database so others could use them without OJB?

Yes! It's generally a good idea to let the DB maintain data integrity as much as possible. OJB was designed to work smoothly with existing databases.
The ODMG transaction manager also takes care not to conflict with database foreign key constraints.


If you want to sync OJB and non-OJB apps working against the same db you have to take care of at least two issues:
1. Autoincremented Sequence Numbers. The Default OJB SequenceManager is not aware of external processes. So you have to use a SequenceManager implementation that uses database managed sequence numbers (or Identies). There are several such implementations in the sequenceManager package.


2. All processes working against the db should use optimistic locking to avoid data disintegrity. OJB supports OL based on Version and timestamp columns.


My compliments to Thomas, Armin, and the team that created OJB. None of this fear is a reflection on your excellent work. It has more to do with the fact that this is still a version 1.0 release candidate and my own ignorance. Sincerely, MOD

thanks for the compliments, cheers Thomas



--- Thomas Mahler <[EMAIL PROTECTED]> wrote:

Hi Bonnie,

Bonnie MacKellar wrote:

I was not at Mobius before 1999, so I really would

not know...


Yes, this is for an important project and I am not

feeling


very good about this. The alternatives though, are

to buy


something or do it ourselves. Our company tends to

be of


the "do it yourself" mentality. Since what we

need is exactly


what OJB provides, it seems silly to replicate it.
On the other hand, it is often easier to deal with

bugs


in your own code then with bugs in someone else's

code.


OJB is 3 years of heavy designed code by experts in
the O/R area.
We have a complete regression testsuite that covers
each and every aspect of the system.


Do it yourself is definitely a bad idea in this
area. If you don't trust us better use a commercial tool like TopLink.


OJB is in production use in large projects for 2
years now.
My company is using OJB in several large and mission
critical software projects since a year now.



I would feel a lot better about this if the mail

archives


worked. My usual approach with this kind of system

is


to really sift through user archives, looking for

similar


experiences.

I admit this is really annoying. But this is clearly
not an OJB problem, but an infrastructure problem with some Apache
server.
For the time being use archive mirrors at GMANE or
at



http://www.mail-archive.com/ojb-user%40db.apache.org/


cheers,
Thomas


Bonnie

-----Original Message-----
From: Michael Duffy [mailto:[EMAIL PROTECTED]
Sent: Friday, March 28, 2003 1:19 PM
To: OJB Users List
Subject: RE: regression test errors



Bonnie,

I'm responding to a note you sent to the OJB

mailing


list.

Is Mobius based in the NYC area? I knew a guy

named


Howard Deiner who worked at a company named

Mobius.


His tenure would have been prior to 1999. Just
curious.


Also curious - will the system you'll be

installing


OJB into be a large production application? I've

been


getting OJB up and running for a smaller

production


project, and I'm nervous about it.  I see all the
problems on the mailing list and sketchy

documentation


and wonder what I'm getting myself into.  JMHO, of
course.  Are you feeling the same way?  Thanks -

MOD



--- Bonnie MacKellar <[EMAIL PROTECTED]> wrote:



Thanks for the advice.
This parameter is set in



C:\db-ojb-1.0.rc1\target\test\ojb\repository_database.xml,

right? Do I need to change anything else to modify
this behavior?

I'm still trying to feel my way around this

system.

Basically, I have
about a week to make a recommendation on using it,
in a large project.
Ease of use is an important consideration,
especially to the powers-that-be
who are managing this project.

Bonnie

-----Original Message-----
From: Armin Waibel
[mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 26, 2003 6:42 PM
To: OJB Users List
Subject: Re: regression test errors

Seems a problem with the used sequence manager
(SequenceManagerHighLowImpl).
Try to run the test cases with
SequenceManagerInMemoryImpl
Do you get the same results?





__________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness,

live on your desktop!


http://platinum.yahoo.com



---------------------------------------------------------------------

To unsubscribe, e-mail:

[EMAIL PROTECTED]


For additional commands, e-mail:

[EMAIL PROTECTED]





---------------------------------------------------------------------

To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]




__________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to