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: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
>
>
> ---------------------------------------------------------------------
> 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]
