Re: Any guidelines or best practices for OJB ?

[Thomas Mahler <th...@web.de>]

Hi Theo,

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 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)
> 
That'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.
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.
>   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) 
>
No general rule here. it really depends on the domain model.

> - 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: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
> 
> 

Re: Any guidelines or best practices for OJB ?

[Joerg Lensing <in...@softcon-lensing.de>]

hi ojb-users,
i found it very useful to read this thread. How about integrating it in 
the user-docs?

joerg

RE: Any guidelines or best practices for OJB ?

[Theo Niemeijer <th...@juras.org>]

Thomas, 
Thanks a lot for your elaborate reply. 
It was just the thing I needed before taking on the
trail of migrating to OJB 1.0 :->
By the way, thank you all for your hard work, 
and be assured that we find it useful and elegant. 
Cheers,
	Theo Niemeijer


> -------------------------------------------------
> Subject: Re: Any guidelines or best practices for OJB ?
> 
> 
> Hi Theo,
> 
> 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 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)
> > 
> That'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.
> 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.
> >   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) 
> >
> No general rule here. it really depends on the domain model.
> 
> > - 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: ojb-user-unsubscribe@db.apache.org
> > For additional commands, e-mail: ojb-user-help@db.apache.org
> > 
> > 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
> 
>