Well, I think what makes it interesting is that the simultaneous write issues don't just apply to ZODB, but the indexes (and/or balancing data) inside the encrypted buckets being maintained by the clients to maintain their own bsts, per my question above. You can't just put a transaction around one bucket because they have to, together, form a consistent tree.
That's especially true when you consider that to maintain log n the tree will have to be a self-balancing tree, so any given modification can touch a larger number of nodes during rotation.
I might be missing something obvious, but if the client has to maintain the tree I have a hard time seeing how you wouldn't have to queue access into the tree for modifying operations. That seems like it could be a pretty significant issue for some applications.
I think, your points are largely correct. You indeed need to lock multiple buckets when you commit data which could be slow.
My point is that you can tolerate that if your application is something like gmail. Client A has his own tree saved on the server, not intersecting with the tree of client B. Client A probably is not going to write from multiple places simultaneously too often.
But if you have groups of clients writing to the same tree, I think it's better to have some writing client which handles multiple commits of others.
Comments
Well, I think what makes it interesting is that the simultaneous write issues don't just apply to ZODB, but the indexes (and/or balancing data) inside the encrypted buckets being maintained by the clients to maintain their own bsts, per my question above. You can't just put a transaction around one bucket because they have to, together, form a consistent tree.
That's especially true when you consider that to maintain log n the tree will have to be a self-balancing tree, so any given modification can touch a larger number of nodes during rotation.
I might be missing something obvious, but if the client has to maintain the tree I have a hard time seeing how you wouldn't have to queue access into the tree for modifying operations. That seems like it could be a pretty significant issue for some applications.
I think, your points are largely correct. You indeed need to lock multiple buckets when you commit data which could be slow.
My point is that you can tolerate that if your application is something like gmail. Client A has his own tree saved on the server, not intersecting with the tree of client B. Client A probably is not going to write from multiple places simultaneously too often.
But if you have groups of clients writing to the same tree, I think it's better to have some writing client which handles multiple commits of others.