IRC log of #zodb for Thursday, 2013-08-22

*** fdrake has quit IRC01:32
*** agroszer has joined #zodb10:14
*** agroszer has quit IRC17:34
*** JaRoel|4d has quit IRC19:32
*** agroszer has joined #zodb20:11
*** agroszer has quit IRC21:05
*** LeoRochael has joined #zodb21:37
LeoRochaelWhat happens if I call ZODB.DB(conn).open() twice in the same thread? Do I get two independent caches?21:38
*** JaRoel|4d has joined #zodb21:54
J1mLeoRochael, yes.22:34
J1mexcept they're share the thread-local transaction manager.22:34
LeoRochaelSo, as long as I don't try to store objects from one into the other, things should Just Work(TM), right?22:35
LeoRochaelJ1m: I have this CMS like system that I started putting users and content in the same ZODB, but now the system is very succesful, and is expecting, like, a million registered users, with perhaps 10k of them simultaneously accessing the system.22:37
LeoRochaelso I wanted a way to preserve the cache from thrashing, at least for operations not involving the user information22:38
LeoRochaelopening two connections will likely be a stopgap measure.22:38
J1mYou should look at resumelb.22:39
J1mYou should also think about alternate database architectures for cases where eventual consistency (or no consistency) is good enough.22:40
LeoRochaelJ1m: yes, we're thinking of moving users to MongoDB22:43
LeoRochaelwill look at resumelb22:43
J1mWe recently had to fail over a ZRS server when an ssd failed. We had to discard all of our ZEO and object caches and it was quite survivable, because each instance was using different data.22:44
J1mNot sure mongo would be my first choice, but I'm not an expert in those databases...22:45
LeoRochaelJ1m: what would be your first choice?22:46
J1mI would look harder at riak or casandra, but I haven't used any of them really.22:47
J1mI think they have better scalability and availability stories, but I'm not sure.22:48

Generated by 2.15.1 by Marius Gedminas - find it at!