Hi again, Boring, Jeff W, ALBAS wrote: > 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. >
We are also running OJB against DB2 and Websphere on OS390 ! > For us, the lack optimistic locking support is driving us from > OJB.ODMG. OJB / ODMG is a OJB / PersistenceBroker application and can thus use optimistic locking too! > Have you considered this issue? What kind of locking > strategy is your app using? we are using OL here. cheers, Thomas > 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]>
