[Seaside] Re: OmniBase

Adrian Lienhard adi at netstyle.ch
Tue Dec 27 12:34:48 CET 2005


On Dec 27, 2005, at 10:02 , Avi Bryant wrote:
>
> Yes, and both of those things are true, they just might not be true  
> at the same time :)  As you say, OmniBase works fine in Squeak with  
> a single image, but it also works fine with light multi-image  
> usage.  We have an OmniBase app where we do

sure, it depends on how "light" the application is used and how you  
have your data structured. This will influence the likeliness; but, I  
guess, you don't want to count on that because a corrupted db is one  
of the most undesirable things that can happen.

Actually, it was quite astonishing, how simply corruption can be  
reproduced (on Squeak Linux VM). FWIW, here the code:

- first add an OrderedCollection to root
	db := OmniBase openOn: self testDir.
	[ OmniBase root at: 'foo' put: OrderedCollection newPersistent ]
		evaluateAndCommitIn: db newTransaction.
	db close.

- then evaluate this in two images concurrently
	[
		db := OmniBase openOn: self testDir.
		200 timesRepeat: [ [ [ (OmniBase root at: 'foo') add: Object  
newPersistent; markDirty ]
			on: ODBLockingConflict do: [ :e ] ]
			evaluateAndCommitIn: db newTransaction ] ] ensure: [ db close ].

Often you will end up with overlapping data ranges. Loading corrupted  
objects in some cases crashes the vm.

Another problem we ran into was that from time to time the db had a  
deadlock on a persistent object, rendering the db unusable until  
being reset...

Adrian


> staged deployments of new images fairly frequently, keeping old  
> users on the original image while we switch new users over to a new  
> one.  There's concurrent usage for an hour or so every time that  
> happens.  We also routinely do database backups and maintenance  
> (data migration, imports, etc) from a second image while the main  
> image continues to serve users.  This app has been running rock  
> solid for something like 2 years now, and the only data integrity  
> problem we ever had was when the server ran out of disk space  
> (oops...).
>
> But, yes, trying to take advantage of a 4-way server by having 4  
> load balanced Squeak images all accessing the same OmniBase data  
> all the time certainly turned out to be a lot more trouble than it  
> was worth, IMO.
>
> Avi
>
> _______________________________________________
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside



More information about the Seaside mailing list