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]

Reply via email to