i've sort of extended concurreny tests with various scenarios and checks. these checks test for consistensy and proper transactional isolation and atomicity.
but some backends (read: CLSQL) might have problems supporting high level of isolation. so, does it make sense to support weaker isolation "profiles"? i suspect that backend with weaker isolation will just fail. but probably it can pass some subset of tests and get "weak isolation certification". if there are people who think it's important, i'd be glad to here from you. also, postmodern backend passes all tests except one -- creating the first instance of indexed class inside multiple threads. it's pretty same problem as i've described in "class indexing txn problems" message, but with more complexities. problem is actually in creating indices for class. thread that starts first will create index structures and will write into index-cache slot. other threads might see this cache before that first thread commits, and will fail using index btree because of transactional isolation. Ian, you said you know a workaround for this problem. will it work in this case -- disallowing concurrent threads to see index cache slot? if other threads will not see cache before txn commits, they will try to make index themselves. i think we can make sure that concurrent attempts to make index will result into write conflict, and so one of transaction will be restarted. this should also work in case of multiple processes. _______________________________________________ elephant-devel site list elephant-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/elephant-devel
