> I agree. I also don't like ODMG OQL. Thus I implemented the ODMG query layer in a way that allows to use the much handier PB QUeries also inside OJB ODMG apps. (See the faq.html for more details).<
Thomas, I read the FAQ (repeated below) but I am concerned about the last sentence. I know you are using OBJ.PB optimistic locking on one of your projects (os390, db2, websphere & ojb). Can you explain 1) the basic approach to using OJB.PB optimistic locking within a OJB.ODMG based application [and/or point me to a specific example] and 2) what relevance the last sentence has in this context? Thanks, The ODMG implementation relies on PB Queries internally! Several users (including myself) are doing this. If you have a look at org.apache.ojb.odmg.oql.OqlQueryImpl.execute() you will see how OJB Query objects can be used withing ODMG transactions. The most important thing is to lock all objects returned by a query to the current transaction. Jeff -----Original Message----- From: Thomas Mahler [mailto:[EMAIL PROTECTED]] Sent: Saturday, October 05, 2002 3:25 PM To: OJB Users List Subject: Re: PersistenceBroker or ODMG? Hi again Jason, Jason Mihalick wrote: > Thomas, > > 1. Thanks for clarifying the optimistic locking support. > 2. Clarification on the internal tables is an example of where the > documentation could be better. Is there documentation anywhere that > specifies what "special features" you mention that require the internal > tables and how to disable the need for the internal tables? our platforms.html document explains each of the internal tables. As no one ever requested to use OJB without these tables there is no special advice on how to do so. I will add respective note. > When I read the > deployment documentation I thought it said to ensure that those tables > existed. I'd check the doc now, but for some reason all of > http://jakarta.apache.org is down. > The documentation also ships with the distribution (see doc directory). > Other areas where the doc could be better: > -> A servlet example for doing "disconnected updates", where objects are > fetched from the database and displayed in a browser in one request, and > submitted back to the server for update in the database on a different > request. Figuring out how to do this with the ODMG API initially was > frustrating for me. I eventually ditched the ODMG API and started using the > PersistenceBroker API and I like it much better ... particularly the > Querying classes. The packaged servlet example was too simple for what I > needed to do. > We have a full fledged Struts/OJB demo application in our contributions package. I think it's worth a look. > -> Threading. More discussion about how to properly use the API(s) in a > multi-threaded environment. It took a lot of reading on the mailing lists > to figure out how to handle this issue, which I still have to implement if > we end up selecting OJB. > We have some threading testcases, but I think they are not very useful as code templates. All users that have interesting solutions that could be helpful for others are requested contrbute theirs code along with a short explanation. We will add such best practises examples to our docuemntation (or if a certain size is exceeded to the contribution package). > -> The more query examples the better. Hibernate does pretty good here. > They have many examples on using the querying language (which, incidentally, > thus far I think is harder to use than the OJB PB Querying classes). There is the query.html documentation. There are also tons of query samples in the testcases. As always: user examples are most welcome ! > -> A matrix (or Pro/Con list) to compare each API within OJB > (PeristenceBroker, ODMG, JDO) would be helpful. Good idea. I'll try to setup such a list. > I first picked the ODMG API > when I started because I thought it would be good to stick with a standard. > After converting to the PB API, though, I think it's much easier to use and > my code is much simpler. PB gives you more control, it's much faster and you have the nice PB queries. On the other hand you have to do a lot of things explicitly that are hidden by ODMG. (e.g. determination if an INSERT or an UPDATE is necessary for a certain Object) > If I had known that the PB API had these > qualities, I don't think I would have spent anytime looking at the ODMG API. I get your point. I once placed a comparison of ODMG and PB into the faq.html. I will extend this section with your pro/cons list. > -> I like the style of the Hibernate docs, presented in a user guide format, > easily navigable. I'll have a closer look at it. > > 3. Performance. The person that wrote the thread about performance, said > that they did some kind of performance test with both and that there was a > factor of nine difference between the two. A bold statement, and one that > deserves a gander I think. On the hibernate forum: > http://sourceforge.net/forum/message.php?msg_id=1645215 > I read the whole thread. There was only a claim, but no further proof or anything. I won't spend my time commenting on such FUD. I want to see the test code and I want to see relevant information on the environment and I want to see exact figures. > 4. All that being said, after trying a parallel test with Hibernate, I'm > not sold on their API as of yet. I am experiencing some problems with > many-to-one mappings on composite keys that I didn't experience with OJB. > Also, with the little bit of coding I've done, I think I like the OJB > querying classes better. The less writing of SQL/OQL-like code, the better > I think. I agree. I also don't like ODMG OQL. Thus I implemented the ODMG query layer in a way that allows to use the much handier PB QUeries also inside OJB ODMG apps. (See the faq.html for more details). We are running this "mixed" mode in several mission critical applications for our customers. > Also the less code I have to write to build query strings the > better. assembling query strings (be it SQL or OQL) hurts my object oriented aesthetics too. > For instance writing a dynamic query in Hibernate that corresponds > to the following SQL was cumbersome: > > SELECT * from customer where customer_id IN ( 1, 2, 3, 4, 5) > > Whereas the same query in OJB is simple. > > Glad to hear that you are operating under the same environment that we are > targetting! I may have DB2 OS/390 questions for you in the future (but > hopefully everything will just *work* when I move from HSQL to DB2). > We had several problems with context switches (from the webserver account to the technical application account used inside DB2) of the DB2 driver. But AFAIK these issues are fixed in Version 7.x. To avoid problems you should start as soon as possible to test your stuff on OS/390. There are a lot of lessons to learn (not at all OJB related !). If you have any problems don't hesitate to ask. cheers, Thomas > Thanks, > Jason > > > ----- Original Message ----- > From: "Thomas Mahler" <[EMAIL PROTECTED]> > To: "OJB Users List" <[EMAIL PROTECTED]> > Sent: Friday, October 04, 2002 3:34 PM > Subject: Re: PersistenceBroker or ODMG? > > > >>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?listName=ojb-user@jakart a.a >>>pach >>>e.org&msgNo=2809 >>>http://archives.apache.org/eyebrowse/ReadMsg?listName=ojb-user@jakart a.a >>>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]> >> > > > -- > 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]>
