Hi Michael,
My company was looking for a object-relational mapping tool
We wrote a lot of junit-tests to test Jakarta OJB.
My conclusion is that OJB is a great product.
I have a lot of ejb-experience, and in my eyes
OJB is a much better solution than entity beans.
I really hope that Sun realizes this also !
We will use Jakarta OJB for our projects, in the following configuration :
1) For performance reasons, we will use the OJB - kernel. (not JDO, not
ODMG)
2) To be independent of the api, we have written a few wrapper-classes.
3) To make our application thread-safe, we have disabled the object caching.
Anyway, if your database is feeded by multiple processes, object caching
MUST be disabled.
4) We will use an adapted version of OJB 0.9.5
We have made some changes in the source-code because OJB doesn't
take into account JDBC transaction isolation levels.
When you are using proxies, in combination with a JDBC READ_COMMITTED
isolation level
it's possible that your program blocks because the proxies use internally
another
JDBC connection than the current one.
I have sent a test and a copy of my changes to the developpers, but I am
not sure whether
these changes will be accepted.
5) We will never use the client/server OJB configuration.
If you need clustering, load-balancing, ... it's better to use an
application server.
In that case session beans are used as a facade, ojb-beans as a
replacement for entity beans.
6) In combination with OJB, we use our own query-engine.
This query-engine is used in case we need overviews, reports,...
where the information is coming from different (joined) business objects.
All sql's can be defined in an external file, called
'repository_sql.xml'.
Each sql can be mapped to a bean.
So when an sql is executed by the query engine, a collection of beans
will be returned.
7) We will use the OJB Optimistic Locking mechanism. (timestamp)
That's the way to handle 'LONG TRANSACTIONS'.
8) For all relations, we have
- enabled auto-retrieve in combination with reference-proxies and
collection-proxies
- enabled auto-delete in case of a composite aggregation
- disabled auto-update (performance!!!)
9) We assume that a JDBC2.0 compatible driver is used.
This is important because OJB and our query engine assume that the
reusltsets are scrollable.
Using scrollable resultsets is the way to implement a performant fetching
mechanism.
ex. fetch 1 : object 1..20 of 100
fetch 2 : object 21..40 of 100
....
10) For primary key generation, we use SequenceManagerHiLoContinuousImpl.
It's a great implementation (performant + thread safe)
Greetings,
Frank Renaers
-----Original Message-----
From: Michael Ochtrop [mailto:[EMAIL PROTECTED]]
Sent: woensdag 2 oktober 2002 10:24
To: OJB Users List
Subject: RE: Real Project with OJB (...continuation)
Hi,
I wasn't quite finished with my previous mail (just a little to quick with
my fingers..)
So let me try again:
1. Criteria
The criteria for choosing one tool before the other are usability,
stability, performance and features (which also includes supporting
standards). For our purposes performance is very important. But
However, I believe that usability is just as important because it
can reduce the time of development and thus saves money.
2. Alternatives
As an alternative we have discussed hibernate. It seems to be very
mature, easy to learn, well featured and fast(?).But since we have
already invested quite a lot of time in using OJB we don't really
want to switch (we don't have enough resources to check out everything
in detail).
Another alternative is to choose a commercial product which
could offer extended support (you don't end up in some dead end, wasting
too much time by trying to figure out how to do something, you just call
the hotline...). But we have read some reports (java-magazine) about
those alternatives and they weren't exactly very convincing. Plus we
have had some experiences with commercial support in other components
that we use, which were more than just disappointing.
3. Documentation
The documentation is quite well. Yet still, I have had problems getting
started with certain features (like joins). That might be my problem
(reading to superficially, lacking certain basics) but it could have
gone faster with more examples. Sometimes it takes a while to figure out
whether something is not working becuase it just doesn't with OJB or
because I messed up. So it is interesting to find out other people's
experiences.
bye
Michael
-----Ursprungliche Nachricht-----
Von: Michael Ochtrop [mailto:[EMAIL PROTECTED]]
Gesendet: Mittwoch, 2. Oktober 2002 09:43
An: OJB Users List
Betreff: RE: Real Project with OJB
Hi,
thanks for your reports on your current projects. We have
started to use OJB in our project as well, but then had certain
doubts which I tried to explain in my proveious email.
The criteria for choosing one tool before the other are usability,
As an alternative to OJB we discussed hibernate or other commercial
tools. We
-----Ursprungliche Nachricht-----
Von: Thomas Mahler [mailto:[EMAIL PROTECTED]]
Gesendet: Dienstag, 1. Oktober 2002 20:30
An: OJB Users List
Betreff: Re: Real Project with OJB
Hi Michael,
Michael Ochtrop wrote:
> Hi,
>
> I would like to know, if anybody on this list has already
> accomplished a real project with OJB.
YES! We are running several Struts/OJB based applications for our
customers. We using an architecture very close to the beer4all
struts/ojb demo by Chuck Cavaness.
There have been no performance or stabilitity issues so far. We are
running our app under Tomcat and WebSphere. I hope we will have a
WebLogic showcase soon.
There have been some problems:
- It is difficult to use OJB with legacy databases that violate 2nd
normal form as OJB relies on primary keys.
- We could not use OJB queries in some cases and had to use hand coded
SQL with QueryBySql.
> My company has (almost)
> decided to use OJB in one of our current projects (a webbased
> catalogue and online-shop with about 20000 products where each
> product consists of 5-20 properties).
>
What alternatives are you discussing? what are the criteria to choose
one tools before the other?
> Now there are some aspects about OJB which I consider to be
> rather difficult or which I can't really judge yet. So I would
> like to hear if somebody has made some _real_ experiences
> (other then just "checking out OJB") with the following questions:
>
> - Is OJB stable enough to handle real projects?
> (There have been various bug reports on the list, e.g.
> concerning joins which I consider essential)
>
In our projects we did not find any OJB bugs yet.
(Of course there are bug reports on the list. There are 3.000 - 5.000
downloads per month. With such a large user base we will always find
bugs in our growing codebase. Being open source is a big help to allow
users to detect bugs. If you are using an obfuscated closed source tool
debugging may become hard/impossible.)
> - How much time does the lack of profound documentation cost?
> (If you get stuck, sometimes the manual really doesn't go very
> far. That could cost time and money).
Mhh, being the writer of most of the documentation I feel that OJB
documentation is quite extensive, accurate and covers a lot of in depth
things.
Did you ever have a look at the TopLink manual? reading their manual I
always feel: "sometimes the manual really doesn't go very far. That
could cost time and money" ;-)
Of course documentation can always be improved. What exactly is missing?
>
> - How often do you need a "workaround" due to lacking features?
> (E.g. lacking capability of mapping one class on multiple tables or
> not fully implemented OQL).
We had to use some workarounds as mentionend above. But they where due
to bad legacy data models not due to OJB.
>
> - Has the performance proven acceptable in a real environment even
> though it is slower than native jdbc?
>
No user complaints so far. If you are writing GUI based applications
overall performance won't suffer.
For batch mode apps it may be more adequate to use native JDBC. But this
can slo coexist with normal OJB code.
cheers,
Thomas
>
> Thanks for any feedback
>
> Michael
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
