Are you posting this somewhere in the swiki?

On Fri, 9 Jul 2004 14:47:16 -0700, Avi Bryant <avi at beta4.com> wrote:
> (My continuing mission to explore new databases, to seek out strange
> bugs, to... never mind).
> 
> Ok, the next thing I'm interested in is reliablity.  IIUC, Magma
> doesn't have a transaction log, which means that reliability is
> definitely a worry: is it possible for me to corrupt the database?  How
> easy is it to lose data?
> 
> I'm starting a new session, and I'm going to leave it in a loop
> committing the current time as quickly as it can:
> 
> [[mySession commit: [mySession root at: 'now' put: Time now]] repeat]
> fork
> 
> Actually this is interesting - what happens when I try to read that
> time, while the commit loop is running?  Create a new session, try to
> access that key:
> 
> mySession2 root at: 'now'
> 
> Hmm, back to the silent-failure issue from part II.
> 
> Create a third session, same problem.
> 
> Well, hm, what do I do now?  I guess I can halt the ever-committing
> process and see what happens then.
> 
> Open the ProcessBrowser to try to kill the process (next time, keep a
> reference to it in the workspace), and the only one that seems right is
> currently in UndefinedObject>>handleSignal:.  Maybe we hit an error
> while trying to commit?  Try to debug the process, my image hangs.  Ok,
> trash that one.
> 
> New client image, open a new session, which seems to work - the server
> survived.  That's good.  But there's nothing at 'now' in the root.  Did
> *none* of those commits work?
> 
> Let's try that again with a delay between commits.
> 
> [[mySession commit: [(Delay forSeconds: 1) wait.  mySession root at:
> 'now' put: Time now]] repeat] fork
> 
> Same problem: trying to access 'now' doesn't work.
> Well, maybe I've screwed up the root object somehow.  Doesn't seem to
> be a way to reset the root, so I'll start a new repository on the
> server.
> 
> Start a new repository, start a server console going, try to repeat the
> test, hit the exact same issue.  I wonder - are there issues with
> having concurrent client sessions in different threads?  Instead of
> forking, let's try repeating this commit some finite number of times...
> 
> 1000 timesRepeat: [mySession commit: [mySession root at: 'now' put:
> Time now]]
> 
> Ok, now try to access it:
> 
> mySession2 root at: 'now'
> 
> Oops, same problem.  Create a new session?
> 
> mySession3 root at: 'now'
> 
> Ok, that worked.
> 
> Now, let's try killing the server while that repeating commit is going
> on.
> 
> 1000 timesRepeat: [mySession commit: [mySession root at: 'now' put:
> Time now]]
> 
> First gently: I'm saving and quitting the server image.  Some notifiers
> popped up about SharedQueue not being empty, but the image quit anyway.
> 
> Just out of curiosity, try to use the client session while the server
> is down.  My image locks up.  After a while, I manage to interrupt it,
> inside a critical section in MaTcpRequestServerLink>>submit:.
> 
> Ok, I bring the server image back up, close the notifiers, and start
> the console going again.
> 
> Try to connect from the client, but it locks again.  Do I need to
> manually signal that semaphore?
> 
> Try that, but still can't connect.  Let's switch to a new client image
> too.
> 
> Ok, that took quite a while, but it did connect.  Try to inspect the
> root, but all I get is the silent-failure thing again.
> 
> If I look back at the server image, I've got an MNU for UndefinedObject
> of
> #maRead: bytes:bytesFromPosition:of:atFilePosition: .  Looks like the
> file is nil?  But it does exist:
> 
> Saba:~/Documents/Squeak/magma avi$ ls -l
> total 192
> -rw-r--r--  1 avi  staff  44592  9 Jul 12:40 myrepos.magma
> -rw-r--r--  1 avi  staff  53184  9 Jul 14:21 myrepos2.magma
> 
> Hm... maybe starting up the server console on restart was a bad idea,
> maybe it does that for me and I should leave it alone.  Quit the server
> image, start it up again.  Use a fresh client image too.
> 
> Nope, same problem.  Maybe I hosed the server image by saving and
> quitting it?  I'll try a brand new server image and use the same
> database file.
> 
> Ok, that seems to work, and I get the root back ok.  Lesson learned: do
> not save and quit a running magma server.
> 
> Next question - what happens if I kill the process instead?  Start the
> repeating commit going, then force quit the server.
> Start up a new server image.  Trying to connect from the old client
> image hangs; start a new client image too.
> 
> Ok, can connect, but can't get the root - same old strange
> silent-failure business.  Now I'm really stuck - this is a fresh server
> image and a fresh client image, and all I've tried to do is connect and
> look at the root.  Is my data gone forever?
> 
> Well, I think that's about as far as I'm willing to go today.  Frankly,
> it's a lot further than I would go if I were evaluating Magma for use,
> rather than trying to give as much feedback as possible - I hit enough
> issues along the way that I would have long since lost the ability to
> muster the 110% confidence I would need to entrust my data to it.  But
> I recognize that it's a work in progress, and so I hope my notes prove
> to be useful in taking it further.
> 
> Chris, if there are particular issues I found that you want help in
> reproducing, just let me know.
> 
> Cheers,
> Avi
> 
>