On May 25, 9:38 am, Peter <peter.r.fos...@gmail.com> wrote: > Hi Rich, > > Still can't reply on that thread, but I was able to start this one. > > "MVCC history in Clojure's STM is dynamic, created by need. There > is no > read tracking, and more important for this case, no transaction > tracking." > > What's the issue with keeping a singly linked list of transactions to > set up object dependencies so that the GC can trim your history list > for you? You only add to the list, it gets GC'd so you don't have to > touch it again. I can get my transaction time-stamp and add to the > list by relying on just 1 AtomicReference CAS. The overhead seems > minimal. > > I've had a play with this and the only real issue I've found is that > doing a Thread.sleep(5000) in the middle of a read-only transaction > will cause your histories to become long because values are changed. > But they GC after the transaction finishes. So a badly performing > transaction that blocks may end up using all available memory for > history. > Other than that, letting the GC do the work seems to be a more > efficient and > simpler approach. > > I was just curious about the reason you decided to go for the manual > approach, that's all. Maybe there is something I hadn't considered. >
I'm not sure I understand what you are proposing. No part of a list of history will be GC'ed as long as anyone holds the head. And what is the relationship between a transaction and its reads without read tracking? Adding read tracking and a global list of transactions is much more overhead than the current STM. Rich -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
