As no one else answered I share some thoughts.
Theo Niemeijer wrote:
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)
Although I know SqlServer from past projects I have no personal experience with OJB + MS SqlServer.
The general recommendation is to always use the latest release as part of a continous integration dicipline. We are doing this for all libraries that OJB depends on. See: http://cvs.apache.org/builds/gump/2003-03-11/db-ojb.html
- We use OJB in single server mode, with its own connection pooling.
Using OJB C/S mode is definitely not recommended.
I have no general tips wrt. connection pooling. It depends a lot to your actual environment. With most app servers you won't have to rely on OJB con 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.
You could also use OJB GUIDs. They are based on a VARCHAR field.
- We heavely use proxy references, and collection proxies,
using the 'proxy="true"' idiom.
Good idea for "normal" applications. special scenarios could possibly benefit from not using proxies.
- 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.
PB is a good choice if you
- want maximum performance and flecibility
- are not bound to a standard API
- are willing to implement some higher level "persistence-manager" functionality on your own
I know several projects that use a lot of QueryBySql statements. Of course you loose some "purity" and code beauty, but it may be a good choice for special problems.
We had no problems in those problems so far...
- We do not use ODMG or JDO at all. We have quite complex queries expressedThat's one of the benefits of the PB. It allows you to build your own higher level persistence functionality by providing a flexible and rock-solid foundation.
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)
If you are aware of the limited semantics of the PB you can build extremely powerful persistence managers on top of it. Our ODMG and JDO layer are examples for this.
- We have quite a lot of domain objects, most of them in several levels of hierarchy, all mapped in the repository.No general rule here. it really depends on the domain model.
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.
In the business frameworks my company develops on top of OJB we also use a persistent base class. this makes it much easier to provide framework services to all entity objects.
- 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.
In our frameworks we provide delegation mechanisms that allow to use
Swing, Servlet (Struts) and generic Webservices clients to access the OJB based business logic either
- through a direct inmemory call
- using SessionBeans
- using RMI
- using CORBA
This allows us to use one and the same business logic and a wide range of execution environments.
E.g.
- in WIndows2000, Tomcat servlet apps.
- in MVS WebSphere based applications
- on HP Nonstop Server Corba environments,
etc...
- 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.
Good idea!
- 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.
Did you try the refresh="true" attribute on reference- and collection descriptors?
- 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).
best performance guaranteed! (JavaBeans access is slower)
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.
We have been using OJB in several larger scale apps already. We had no big performance issues so far.
I agree that there are a lot of bells an whistles with OJB. We try to make it simpler by providing kits (composed of a set of configuration settings) that cover several app scenarios.
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,
All ideas are welcome. Jakob is doing a great job in implementing new features to the SQL generator!
and sometimes I thinks that the generated database statements are a littlebit confusing :->
sigh. I have not seen an intelligent code generator so far. the OJB mechanisms are nothing special in this respect :-(
thanks for sharing your ideas and findings. I feels such discussions can be beneficial for many users.
cheers, Thomas
Cheers, Theo Niemeijer
--------------------------------------------------------------------- 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]
