Hi Kamen, I have cross-checked the problem you pointed at, and in fact it is true: The file copying operation of the blob creation routines is not guarded against other processes accessing the datastore. I have not delved into this very far, but I suspect that under CMUCL and SERVE-EVENT based multiprocessing, no scheduling will occur during the file I/O operation, as the scheduler will run only when a file descriptor under control of the SERVE-EVENT subsystem is accessed. This is a guess only, though, and I have not looked up the source to verify what's going on. With a threaded Lisp, the mechanism could be much more problematic as the scheduler may run at any time and pre-empt the Lisp process, possibly in the middle of the file-copying operation. It depends on your application if this is a problem. If your application does not use the blob until it has been put into some application-defined data structure (as opposed to using the class' index), the incomplete blob will be no problem - Only the external data will not be complete. As we started implementing the datastore, we decided that the blob I/O operations should not be protected by the datastore locks, as this would possibly stall the system for a long time. This may or may not be good for your application, but it would require further analysis to really make a good judgement if blob writing should be further protected. This could, for example, be done with a "complete" slot that would be set after the blob has been completely written, in a seperate store transaction. Note that cmucl provides cooperative multiprocessing which is preferable to preemptive threading in many respects. It is simpler to understand, implement and debug. The only real disadvantage it has (in my eyes, anyway), is the fact that no two processes can run at the same time, if two CPUs are available. Cheers, Hans