Inside the latest jakarta-ojb-0.9.7-contrib.tgz you'll find an archive struts-ojb-zip
cheers, Thomas Boring, Jeff W, ALBAS wrote: >>We have a full fledged Struts/OJB demo application in our > > contributions package. I think it's worth a look.< > > Where? All I see in the contributions package is the doc-book stuff. I > assume you are referring to "jakarta-ojb-0.9.5-contrib.tgz?" > > 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]> > > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
