well, so what you seem to write is that your application is architected around a generic function that serializes mutations, and that not having BKNR transactions support generic functions prevented you from just using them rather than implementing your own lock. Fair enough. I wonder why you can't use multiple generic functions instead of one, but that is beyond what I can (and want to) understand right now. The generic function issue is just an additional "cost" for using
Hi Hans, transactions. The main point is that I see no benefit from transactions. I'm sorry I didn't made that clear earlier. (I don't want to claim there is none, maybe I just don't see it or it is related to my scenario.)
STM is interesting, but real transactional memory interests me more, I must admit. There is an implementation of CLOS STM (http://common-lisp.net/project/cl-stm/), but the lack of support for non-CLOS data types is kind of a show-stopper for me. Maybe someone will hack STM into one of the CL compilers, but I'm not really prepared to do that. Thanks for the hint, though I have to agree that non-CLOS is essential.
Anyway - If you need further support with BKNR indices, let us know.
Is it somehow possible with the datastore to run different stores in one lisp process? For example to run multiple instances of the same web-application on the same port on the same machine. Besides the problems mentioned I have to add that I am really happy with the concept of indices and the relief from traditional DBMs and ugly DB -> OO mappings misleadingly claiming to be transparent OO -> DB mappings. I gladly pay the scalability price for that, and I'm looking forward to gain more experience with that paradigm. I'll also have a closer look on the web framework aswell, it looks very promising! Assuming no immediate projects/deadlines, do you think it is a good idea to wait until the summer release? Thanks for your patience (: - Klaus