Hi all.
I hope this post is not to long to read.
I am working with OJB for several months now,
and although I am quite happy with its existance,
I still have that nagging feeling that I am doing
things wrong :->. Or that things that seem strange are
simply caused by my own misunderstandings.
So what I would like to now: Can anyone with experience offer
some "best practice" guidelines ?
For starters I will tell how we use it:
- We use MSSQL Server, with JBoss app server,
and are still using 0.9.5 for production.
(I have tested with 1.0rc1, and it seems to work
after changing some deprecated method calls. But I do
not dare to put it in production yet because of some
subtle or not so subtle changes that were introduced)
- We use OJB in single server mode, with its
own connection pooling.
- We have unique global identities, so each
objects has a unique key, using
SequenceManagerHighLowImpl (compatible with HiLo I think)
We use an Integer field as the key.
- We heavely use proxy references, and collection proxies,
using the 'proxy="true"' idiom.
- We only use the Persistence Broker API, making queries with the Criteria
objects and getIteratorByQuery and getCollectionByQuery.
We tried to not use the addSql() method, but could not avoid it
in some places.
- We do not use ODMG or JDO at all. We have quite complex queries expressed
as OJB Criteria, and were attracted by the portable way these could
be expressed, and transferred from client to server. Extra
criteria are added for things like access rights and 'views' based on state.
(front office sees a different 'view' than back-office)
- We have quite a lot of domain objects, most of them in
several levels of hierarchy, all mapped in the repository.
The main domain hierarchies are are each mapped to a single
table. The many relations are made between the abstract base
objects of such a domain hierarchie.
(Activities, Resources, Events, Articles, Locations)
- We mapped our domain objects directly on Java objects, but added
OJB support (beforeStore) to add things like "createdBy", "creationDate",
"modifiedBy", "modifiedDate" etc. Therefore we use a PersistentObject
base class that has the unique key and such.
- We actually use separate Tomcat web servers, connecting to
the JBoss app server Session EJB's, which in turn use
the OJB persistence broker. Result objects and
collections are transferred to the client.
- Transactions are not used for complex stuff, only for the
simple operations that are done with a single call to
a facade session EJB. So no transactions over a series
of EJB calls.
- We try to remove objects from the cache after any store operation
that involves several objects, because we got the feeling that
referenced objects and collections are not refreshed, causing
objects to mysteriously "re-appear" via references.
- We use the directly mapped fields (I mean not via getters and setters,
but the fields are directly accessed by OJB when an object is
materialized).
And there is more of course. But the thing is, OJB offers a lot
of choices, and some of them do not seem to scale very well.
I sometimes feel it is not a safe bet in such an "enterprise
application" (I mean here with the use of JBoss and with separate
webservers, and high loads and possible concurrency)
I would like to hear from others that use OJB in somewhat
larger scale.
Overall I am quite happy with the functionality that is offered,
but sometimes it can be frustrating to work around limitations in the
criteria expressions, and sometimes I thinks that the generated database
statements are a littlebit confusing :->
Cheers,
Theo Niemeijer
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
