RE: Any guidelines or best practices for OJB ?
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", "c
Re: Any guidelines or best practices for OJB ?
hi ojb-users, i found it very useful to read this thread. How about integrating it in the user-docs? joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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
Any guidelines or best practices for OJB ?
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]
