Luckily the system I'm on doesn't have much concurrent writing of the same objects going on from different app servers/users - it's pretty much a single user logs in and does things to their profile or performs read-operations on other objects. I would like to cover the less than 10% areas where this could be a problem though. I looked through the OJB code and found a class called ObjectCacheJCSImpl written by Matthew Baird, but I'm not sure how to use it, what its working status is, etc. I didn't see any comments in the code either.
I've worked with a few other data access layers like OJB and they didn't address the distributed cache problem either, so I don't feel particularly left out in the cold here. The cache mechanism in OJB seems simple enough to plug in something to manage it. Btw good job guys on the latest version, it's a great improvement from what I was running on 0.9.7. Ryan -----Original Message----- From: Armin Waibel [mailto:[EMAIL PROTECTED]] Sent: Friday, February 21, 2003 3:34 AM To: OJB Users List Subject: Re: is this an old .97 bug? (sequencing) - happens in 0.9.9 too Hi Ryan, indeed that's a better workaround for the problem. But the same problems (you have with HighLowSequence) could occur with any other persistent capable object. Say server1 and server2 cache object A, now server1 update A-->A'. Then server2 do a select for A and found A not A'. Server2 never will get the update version of A. Thus you need a distributed cache (JCS or a JMS based in J2EE compilant environments), or a cache only exists e.g. for a transaction, or as long as you do close the PersistenceBroker instance, or a cache implementation remove objects after a specific time period. regards, Armin ----- Original Message ----- From: "Ryan Vanderwerf" <[EMAIL PROTECTED]> To: "OJB Users List" <[EMAIL PROTECTED]>; "Armin Waibel" <[EMAIL PROTECTED]> Sent: Thursday, February 20, 2003 6:25 PM Subject: RE: is this an old .97 bug? (sequencing) - happens in 0.9.9 too I've put the following fix in that isn't quite as much of a performance drain in SequenceGenerator.java, around line 47: broker.beginTransaction(); // temp fix for sequence caching problem newSequence = (HighLowSequence) broker.getObjectByQuery(q); broker.removeFromCache(newSequence); I threw quite a bit of load and it and it still seems to stop OJB from corrupting it's own inserts and updates. Ryan -----Original Message----- From: Armin Waibel [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 19, 2003 7:20 PM To: OJB Users List Subject: Re: is this an old .97 bug? (sequencing) - happens in 0.9.9 too Hi Ryan, > The problem with that fix is that it wipes out the entire application > cache for OJB each time you get a sequence, obviously not a very elegant > solution. Yes, a really dirty hack! A solution could be to introduce a 'use-cache' property in class-descriptor and when set 'false' objects (in particular HighLowSequence objects ;-)) never will be cached, but this only solve the inconsistency for the sequence object. The real problem is caching in clustered/multi-tier environments. Different JVM with discrete caches will ever cause problems. Turbine-JCS supports a remote (client/server) cache but I don't have any experiences in using this. The MetaObjectJCSCacheImpl use the JCS cache. regards, Armin ----- Original Message ----- From: "Ryan Vanderwerf" <[EMAIL PROTECTED]> To: "OJB Users List" <[EMAIL PROTECTED]>; "Armin Waibel" <[EMAIL PROTECTED]> Sent: Wednesday, February 19, 2003 6:11 PM Subject: RE: is this an old .97 bug? (sequencing) - happens in 0.9.9 too Thanks Armin, caching was definitely the problem! The problem with that fix is that it wipes out the entire application cache for OJB each time you get a sequence, obviously not a very elegant solution. A fix for this should definitely go into the source tree though; I'd think it's a pretty major problem. Also disturbing was the behavior of OJB turning the inserts into updates when creating new objects when the sequence tables get off - it should definitely be just calling the insert and allowing the db to throw a key violation if necessary(better than the alternative of stomping on data). Thanks again, Ryan -----Original Message----- From: Armin Waibel [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 18, 2003 6:49 PM To: OJB Users List Subject: Re: is this an old .97 bug? (sequencing) - happens in 0.9.9 too Hi Ryan, maybe it's a caching problem. In SequenceGenerator#getNextSequence(...) the PB-api was used to lookup a HighLowSequence, thus the instance was cached. But interim the other server could update the same HighLowSequence. Now the cached instance was invalid, but was further on used! To check this out, please put in SequenceGenerator#getNextSequence(...) before broker.beginTransaction() the line(~45): broker.clearCache(); call 'bin\build.bat jar' to make the new jar files Any other results? regards, Armin ----- Original Message ----- From: "Ryan Vanderwerf" <[EMAIL PROTECTED]> To: "OJB Users List" <[EMAIL PROTECTED]> Sent: Wednesday, February 19, 2003 12:50 AM Subject: RE: is this an old .97 bug? (sequencing) - happens in 0.9.9 too I've upgrades to 0.9.9 and I can verify this is still happening.I make a copy of a test table that I write to, and I have 2 servlet engines writing to the same database, the each instance of OJB of each server overwrites the OJB_HL_SEQ with conflicting values for each app server. This causes 2 problems: the sequences get further and further off between what OJB things is the max key in the OJB_HL_SEQ table to be FAR less than the MAX key that OJB inserted into the data table of my application. Once that condition occurs, OJB starts re-issuing already used keys to a different app server, and OJB seems to treat that as an update! I can tell my making a copy of my test table, running a load test on both app servers, and doing a diff with a simple sql statement. For example 28508 28508 bV2h94QJL5D6 bvge68b0pXuh 2003-02-18 17:38:03.803 2003-02-18 17:23:11.260 28509 28509 b1jc0yNmnn6- b9say-gdZmW4 2003-02-18 17:38:04.403 2003-02-18 17:23:12.157 28510 28510 bHNClzfCQdg6 b_1fh-u9KFee 2003-02-18 17:38:05.233 2003-02-18 17:23:12.797 28511 28511 bYWI47cflYsc b1fXwwWLHkyh 2003-02-18 17:38:06.270 2003-02-18 17:23:13.563 28512 28512 bV3RKk8ExpR4 bOfxVdUakuR_ 2003-02-18 17:38:07.093 2003-02-18 17:23:14.327 28513 28513 bcWNisFy0yg5 bdbb15HAXEW5 2003-02-18 17:38:07.927 2003-02-18 17:23:15.443 28514 28514 b5gSHTS2kRU5 bA9PpLqcFm1h 2003-02-18 17:38:08.747 2003-02-18 17:23:16.197 28515 28515 bkyVcBKaNYV9 bYx84C7khpRh 2003-02-18 17:38:09.793 2003-02-18 17:23:16.957 28516 28516 bl-108wSMe04 bN1aSMVOpXv6 2003-02-18 17:38:10.613 2003-02-18 17:23:17.713 shows 2 records side by side, the original, and the one OJB blew away on itself. The first 2 cols are the primary key from OJB, the others are the date It was created and the session ID. As you can see it's stomping all over itself. When I get the OJB_HL_SEQ row for by table, it says the primary key was last 27870, yet the max primary key of the table is actually 29017. When I start my load test they are matching. I'm running 0.9.9, SQL Server 2000, and Caucho Resin 2.1.6 appears the HILO sequence manager can't work properly with 2 application servers writing to the same database. Has anyone else here seen similar behavior with 2 app servers? I'm wondering if this is a SQL server thing where it's not locking the rows properly in the OJB_HL_SEQ table or whether OJB even tries to do this. Also of note I'm purely using the PB api. Any suggestions on how I can use OJB in a multi-server, servlet environment? Since SQL server uses identities, I didn't see a way to make my own sequence manager since it has to get the ID after the insert instead of before. Ryan -----Original Message----- From: Mahler Thomas [mailto:[EMAIL PROTECTED]] Sent: Friday, February 14, 2003 3:08 AM To: 'OJB Users List' Subject: AW: is this an old .97 bug? (sequencing) Hi Ryan, > > I've experienced a weird problem in my servlet environment > (caucho resin > 1.2.6, RH8, sql server 2k, 0.9.7 using PB API) with the sequence > manager. Until recently my application has run on 1 > application server, > with a grab size of 10 for sequences (I'm using the HI_LO seq manager) > which was working fine. Now I added a second application > server, behind > a load balancer with the same settings (Sticky source IP). If I had a > problem with sequences I would expect to see UNIQUE KEY constraint > errors in my logs. Instead if 2 instances/servers of OJB grab the same > or overlapping pools of keys, the first insert succeeds. The > weird part > is the second app server then inserts with the same already > used primary > key, and it appears to over-write the record that was already there, > thus eating data and masking the problem by succeeding. Is > this behavior > intentional? Mhh. This is strange indeed. The SQL Server should obviously signal a primary key violation! If it does not it seems to be a problem with the database rather than with OJB. Are you shure you have defined a PRIMARY KEY in the database? If the PRIMARY KEY in the DB does not match the PRIMARY defined in the OJB repository you are likely to get such problems! > Should I be running OJB in CS mode? No. This is not a C/S vs. singlevm related problem. > I've tried > to decrease > the grab size to 1, hoping that will alleviate the problem > until I find > out more. It may be possible that the .97 SequenceManager does not work correctly wrt. serving multiple servers. But this is only one half of the problem. The other half is that the db does not signal PK violations! To avoid problems with the SeqMan you might use (or implement) a different SeqMan that uses SQL Server specific sequence numbering. > I've also heard the CS mode has been broken for a while, so > should I even mess with it? No, this will only add confusion.... cheers, Thomas > > > I'm trying to hold on to .97 as long as I can to get > something closer to > v1.0, as .98 I had to roll back because of some other odd problems. > > > > Thanks for any input, > > > > Ryan > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
