Sorry, I just now read this after sending my last note. So, I see, it does support optimistic locking ... thanks for the clarification, Thomas. I was under the impression that locking was completely controlled by DB2 (because I know both are locking mechanisms are options at the RDBMS level on DB/2 OS/390) and handn't really considered the implications with OJB.
-- Jason ----- Original Message ----- From: "Thomas Mahler" <[EMAIL PROTECTED]> To: "OJB Users List" <[EMAIL PROTECTED]> Sent: Thursday, October 03, 2002 3:55 PM Subject: Re: PersistenceBroker or ODMG? > 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]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
