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]
