Hi again, Jason Mihalick wrote: > Jeff, > > Wow. You are targetting the same platforms as us! As of right now (which > could change very soon depending on support for Struts), we are also > targetting WAS 3.5.
After some trouble wrt. to placing struts-config.xml into the correct classloader path we are running struts apps on WS 3.5 / OS390 without problems. > > You bring up an interesting point. We have not considered locking > strategies. I think that optimistic locking is what we need, but I was not > aware that OJB does not support this. > Once and for all: *OJB does support optimistic locking*. There are several testcases covering this feature. > Also, since I have sent my prior messages, we have discovered Hibernate and > I will be evaluating it today. Hibernate looks *very* promising. Some of > the things I like about Hibernate vs. OJB: > > -> No need for additional system tables to support the API You can run OJB without any internal tables! 1. If you want to use OJB sequence numbers you only have to implement a SequenceManager that does not rely on a table (If users think this is an important feature we can add such a simplified SequenceManager to the main distribution). 2. all other internal tables are only needed if you are using special ODMG features like persistent collections. These collections are specified by ODMG. So you you cannot blame OJB for those tables. > -> Threads I've read say that Hibernate is thinner, giving better > performance OJB is providing a performance testsuite that allows to compare native JDBC performance against PersistenceBroker performance. I'd love to see this test reimplemented for other tools like Hibernate to have a direct comparison. Everything else is mere speculation. > -> Documentation is *excellent* > Hibernate docs are in good shape. It's well structured and written by native english speakers. I'm german and my english is not perfect... But apart from style and grammar: what is missing in OJB documentation? How can we improve the overall structure of the documentation? cheers, Thomas > -- > Jason > > ----- Original Message ----- > From: "Boring, Jeff W, ALBAS" <[EMAIL PROTECTED]> > To: "OJB Users List" <[EMAIL PROTECTED]> > Sent: Thursday, October 03, 2002 10:43 AM > Subject: RE: PersistenceBroker or ODMG? > > > Jason/Suresh: > > I read with interest some of the messages in your tread. We are also > considering PB, ODMG and Hibernate. Another similarity we have is DB2 7.1 on > OS/390 and we are also using WebSphere v3.5 on the 390. > > For us, the lack optimistic locking support is driving us from OJB.ODMG. > Have you considered this issue? What kind of locking strategy is your app > using? > > Jeff Boring > Custom & Web Services Development > AT&T Labs > [EMAIL PROTECTED] > > -----Original Message----- > From: Jason Mihalick [mailto:[EMAIL PROTECTED]] > Sent: Thursday, October 03, 2002 6:09 AM > To: [EMAIL PROTECTED] > Subject: Re: PersistenceBroker or ODMG? > > > This was a response that I just sent directly to another person on the list. > Hopefully it helps... > > > ======== > Suresh, > > No, I have not changed to Castor. Half of my problems were fixed by > refactoring my code to use the PersistenceBroker API instead of the ODMG > API. I was having problems with aborting transactions with the ODMG API. > That aside, I think I like the PersistenceBroker API much better anyway. > The little bit of persistence code that I had written went down from about > 900 lines to 650 lines. From what I've seen so far, it seems like a fairly > elegant API .... AND .... it appears to allow access to a JDBC Connection > which is good for us since we will probably be making calls to Stored > Procedures, which isn't possible under the ODMG API. > > The remaining problems that I need to resolve are the threading issues. I > have read a couple of threads on the mailing list about how to remedy this. > One person suggested that all I had to do was create a new PersistenceBroker > for each query, since the PersistenceBrokers are pooled. I have not > verified this yet, but it sounds promising. Right now, I just have Tomcat > running with a single HttpProcessor thread and things are working. I'll > attempt to remedy the threading issue on our next deliverable. I plan to > continue using OJB assuming (1) that I don't have a lot of issues when I > change our backing database from HSQL to DB2 v7.1 for OS/390, (2) I can get > support from our other team members that OJB is the way-to-go, and (3) I can > resolve the threading issue. > > As far as performance goes, it seems really good to me so far, but at this > point we have only been dealing with small tables, few rows in the tables, > and business logic that supports maintainence of the rows in the tables. We > haven't started doing real query-intensive business logic yet. > > After I switched to the PersistenceBroker API, I must admit that my attitude > about OJB changed significantly. I've stopped fighting it, and have really > been quite productive with it. > > -- > Jason > > ----- Original Message ----- > From: "Avadhanula, Suresh" <[EMAIL PROTECTED]> > To: "Avadhanula, Suresh" <[EMAIL PROTECTED]>; "Jason Mihalick" > <[EMAIL PROTECTED]> > Sent: Wednesday, October 02, 2002 2:51 PM > Subject: RE: Initializing OJB > > > Hi Jason > Have you changed to Castor? Were the threading issues in OJB fixed in > 0.9.6? You reported that QueryByExample was missing in the latest > release. Is this fixed? > What is the performance you see with OJB? > > Thanks > Suresh > > -----Original Message----- > From: Avadhanula, Suresh > Sent: Tuesday, October 01, 2002 3:46 AM > To: 'Jason Mihalick' > Subject: RE: Initializing OJB > > > I just went thro your posts... I have just started using OJB so yet to > encounter the threading issues. > > I am trying out OJB, hence havent exactly made up my mind to ditch > Castor. Although I favour OJB so far. Having said that, here are thee > reasons.. > > Cons: > 1) Castor uses only JDO which is not the standard JDO proposed by Java. > 2) I cannot swith between standards like ODMG, JDO and reflection > (Persistence API). > 3) The code is not very clean and documented, hence if I want to change > anything or figure out anything its a pain. I have had huge problems > trying > to store Maps (Hastables, HashMaps) using Castor-XML. I ended up > using Apache SOAP's serializer in castor FieldHandler which defeats the > whole purpose of using castor. > 4) There are no adequeate tools available except for SourceGenertor > which is used only for Castor-XML and not JDO. > > Pros: > 1) Castor has been present for long time. > 2) Usage perspective, its pretty decent. > > Coming to OJB: > You probably have more experience with OJB than I do. > I am looking at OJB for the following reasons.. Standards, hence if I > choose to go the JDO route or ODMG route.. I dont have to change a lot. > The main reason I like OJB is PersistenceBrokerAPI (which is not a > standard). The reason for that is, I need to have the SQL generated > automatically. > I like the > Query = new QueryByExample(queryObject); // Where queryObject is a > sample object with only some feilds filled in.. > > I was gonna end up writing something similar.. well not OJB gives it to > me. > > As for as the threading issues.. I need to see if I run into the > problems. I doubt that I would as I can request a new PersistenceBroker > everytime as its all pooled > internally. But I need to check. > > Hope that helps. > -Suresh > > > > -----Original Message----- > From: Jason Mihalick [mailto:[EMAIL PROTECTED]] > Sent: Monday, September 30, 2002 6:33 PM > To: Avadhanula, Suresh > Subject: Re: Initializing OJB > > > Would you mind me asking why you are shifting from Castor to OJB? I was > just considering doing the opposite. See my last two posts as to why: > > http://archives.apache.org/eyebrowse/ReadMsg?[EMAIL PROTECTED] > pach > e.org&msgNo=2809 > http://archives.apache.org/eyebrowse/ReadMsg?[EMAIL PROTECTED] > pach > e.org&msgNo=2831 > > Thanks, > Jason > > > ----- Original Message ----- > From: "Hemant Gokhale" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Wednesday, October 02, 2002 8:26 PM > Subject: PersistenceBroker or ODMG? > > > >>I am new to OJB and looking for some advice on choosing between the >>PersistenceBroker and the ODMG API. Thanks in advance for your help. >>We are developing a set of simple servlet based applications. And I >>would like to use OJB for persistence. Our scalability requirements are >>modest. I am looking at less than 10 simultaneous requests. I would like > > to > >>keep the code as simple and small as possible. I plan to use OJB in a > > single > >>VM mode (not client server). >>I have looked at both the options of using the persistence broker >>directly and using the ODMG API. My initial inclination was to use the > > ODMG > >>API. But on closer inspection I found using the PersistenceBroker directly >>would be simpler and potentially faster. The added advantage of using >>PersistenceBroker is that I can use auto-delete and auto-update features > > to > >>make my code even smaller. >>The only problem with this approach is the possibility of two >>threads modifying the same object in the object cache. I came up with the >>following strategy to deal with this problem. >>Can one of the more experienced people please tell me if this >>approach with work? Or am I on a wrong track? >> >>* Create a pool of persistence brokers. The application is expected to >>receive only a few simultaneous requests. So the pool is not expected to >>grow very large. >>* Inside actionObject.perform() method, before any database >>interaction >>* get a broker from the pool >>* start a transaction tx >>* Do all your db access using the tx >>* At the end of all database interaction (still inside >>actionObject.perform() method) >>* either commit or abort the tx >>* release the broker to the pool. >> >> >>Thanks. >> >>-Hemant >> >>-- >>To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> >> > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
