Comments on: A CAL webapp with persistent data using GWT, STM and BDB http://diversions.nfshost.com/blog/2008/03/27/a-cal-webapp-with-persistent-data-using-gwt-stm-and-bdb/ Notes on things I'm thinking and doing Thu, 04 Dec 2008 00:14:52 +0000 http://wordpress.org/?v=2.5.1 By: Tom Davies http://diversions.nfshost.com/blog/2008/03/27/a-cal-webapp-with-persistent-data-using-gwt-stm-and-bdb/#comment-1414 Tom Davies Tue, 01 Apr 2008 20:20:05 +0000 http://diversions.nfshost.com/blog/2008/03/27/a-cal-webapp-with-persistent-data-using-gwt-stm-and-bdb/#comment-1414 <p>Hi Raoul -- I believe that functional data structures don't suit STM, because while you can update, e.g. a tree without replacing many nodes, you are always going to replace the root node, so any concurrent transactions which have read or written the TVar which holds it will retry -- which means any transaction which is concurrent with an update, as everyone who accesses the tree will read the root node.</p> <p>There may be some non-STM approach which would work when concurrent updates are infrequent (e.g. all updates can be performed by one thread). Because purely functional data structures are 'persistent' (as defined by Okasaki) you could have <em>one</em> mutable reference which is updated by the writing thread each time it performs an update, and is read by the other threads periodically -- they will always have a consistent view of your data structures.</p> <p>But that limitation to one writer makes this sound fundamentally non-scalable and unsound -- like Prevayler, for instance.</p> Hi Raoul — I believe that functional data structures don’t suit STM, because while you can update, e.g. a tree without replacing many nodes, you are always going to replace the root node, so any concurrent transactions which have read or written the TVar which holds it will retry — which means any transaction which is concurrent with an update, as everyone who accesses the tree will read the root node.

There may be some non-STM approach which would work when concurrent updates are infrequent (e.g. all updates can be performed by one thread). Because purely functional data structures are ‘persistent’ (as defined by Okasaki) you could have one mutable reference which is updated by the writing thread each time it performs an update, and is read by the other threads periodically — they will always have a consistent view of your data structures.

But that limitation to one writer makes this sound fundamentally non-scalable and unsound — like Prevayler, for instance.

]]> By: Raoul Duke http://diversions.nfshost.com/blog/2008/03/27/a-cal-webapp-with-persistent-data-using-gwt-stm-and-bdb/#comment-1413 Raoul Duke Tue, 01 Apr 2008 18:58:03 +0000 http://diversions.nfshost.com/blog/2008/03/27/a-cal-webapp-with-persistent-data-using-gwt-stm-and-bdb/#comment-1413 <p>since i just got Okasaki's book for my birthday i have to ask what you think about taking a functional-data-structure approach? how would that play with STM etc.? thanks for any thoughts.</p> since i just got Okasaki’s book for my birthday i have to ask what you think about taking a functional-data-structure approach? how would that play with STM etc.? thanks for any thoughts.

]]>