I've found that this is the case in multi-tiered applications where there are few guarantees on data cached in memory not being dirty. The same applies to OJB/JDO. They have their applications, but when you are dealing with critical data on a multi-tiered application, you will usually timestamp the data as the time it was last modified and having to check against the DB on every call anyways.
The only thing it really saves you is replication of objects in memory. But I would opt for a good DAO and stored procedures. BeanUtils has really opened the door for an easy DAO implementation. We were able to write a DAO broker implementation that's configured with XML and has the option of using stored procedures in a few days. Since all of our business objects are interface based, we can just have ActionForms implement the BO interfaces and pass them directly to the DAO for persisting, no need for JBoss or worrying about replicating our SQL schema in Java. With transactions, you can't get much closer to the DB than working with a connection itself. I guess I'm a little more about pushing business logic to the DB itself and burying it in triggers and stored procedures. Again, why replicate all of that in another tier when you should be freeing up the app server to do more important things. Also, for methods that require access to persistent data, it is a good practice to put a firebreak in, or a middle man. If scaling is required at a later time, you can do some caching of objects behind that method, independent of the Action Layer and DAO Layer. I don't know if what I said contributed much, but it's the conclusion we've come to after playing with OJB, EJB, and various DAO implementations. I remember Craig saying that hardware is cheap-- so don't kill yourself with the scalability issue, it's cheaper to throw on a new box in a load balancing situation then to update or rework a whole layer of an application in most cases. -Jacob | -----Original Message----- | From: Peter A. J. Pilgrim [mailto:[EMAIL PROTECTED]] | Sent: Tuesday, September 24, 2002 9:29 PM | To: Struts Users Mailing List | Subject: Re: EJB / was Struts and high performance sites | | Galbreath, Mark wrote: | > Check out http://shop.t-mobile.com dude - the entire site is a Struts + | EJB | > app. If your EJBs didn't scale, you did not know what you were doing. | > | > Mark | > | | I would also say that you pick right database tables to make entity | beans in the first place. This is where the performance probably | failed. You can make SessionBeans pass back RowSet, or HashSet | or DataTransferMaps of the rows of the database table instead. | Especially in a shopping web app. | | Other people have advocate JDO as a replacement for EntityBeans | and I think this technology also works, but I am not sure | if it is distributed or supports the type of transactions that | J2EE / JTA fully endorses. | | Couple of books "EJB Design Patterns" F.Marinescu and | Mr Grand "Java Enterprise Patterns" spring to mind. | | > -----Original Message----- | > From: V. Cekvenich [mailto:[EMAIL PROTECTED]] | > Sent: Tuesday, September 24, 2002 7:26 AM | > | > They are hype marketed as such. Most newer developers try them, as I did | > when I was new, but in production they did not scale, so we removed | > them. On new sites I skip the writing them part, since people would | > only remove them in production. (some management that take EJB to | > production are so upset that they go to the cached .NET ADO, so I steer | > my client's clear). | > | | -- | Peter Pilgrim +-----\ +-++----++----+ | Java Technologist | | | || || | 'n' Shine | | O | | || --+| ---+ | /\ | ._ / | | \ \ | | | / \ | | \ \ | |+-- || ---+ A new day | /_ _\ "Up" | | | | | || || | is coming | || +-+ +-+ +-++----++----+ | <home page="http://www.xenonsoft.demon.co.uk/"; /> | | | -- | To unsubscribe, e-mail: <mailto:struts-user- | [EMAIL PROTECTED]> | For additional commands, e-mail: <mailto:struts-user- | [EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
