We are also using Struts! Perhaps we should stay in touch and compare notes? You see from my address that this is an AT&T project. Would you mind telling me what company your app is for?
What IDE are you using? We are going from VAJava to WSAD. I have not been able to get any of the ojb tutorials to run inside WSAD, although they run fine at the command line. I know of 3 other developers from 2 different companies that get the same error I get ( [DEFAULT] FATAL: no protocol: repository.dtd java.net.MalformedURLException: no protocol: repository.dtd). No one has replied to my post here about this on 9/27/02. Jeff Boring Custom & Web Services Development AT&T Labs [EMAIL PROTECTED] -----Original Message----- From: Jason Mihalick [mailto:[EMAIL PROTECTED]] Sent: Friday, October 04, 2002 6:13 AM To: OJB Users List Cc: Boring, Jeff W, ALBAS Subject: Re: PersistenceBroker or ODMG? 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. 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. 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 -> Threads I've read say that Hibernate is thinner, giving better performance -> Documentation is *excellent* -- 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]>
