Re: preferred way to dereference a ref: outside or inside dosync?

On 23/11/13 14:17, Justin Smith wrote: you may want to make that (defonce generate-keys (get-key-generator)) and even better, add a "start" argument to get-key-generator so you can persist across restarts of the vm. Of course in a real app the key should be serialized to a persistent, consis

Re: preferred way to dereference a ref: outside or inside dosync?

On Saturday, November 23, 2013 3:17:07 PM UTC+1, Justin Smith wrote: > > Of course in a real app the key should be serialized to a persistent, > consistent, and shared data store. > > Which of course depends on the app in question. The code above was taken from a 'real app', if 'an app that is

Re: preferred way to dereference a ref: outside or inside dosync?

you may want to make that (defonce generate-keys (get-key-generator)) and even better, add a "start" argument to get-key-generator so you can persist across restarts of the vm. Of course in a real app the key should be serialized to a persistent, consistent, and shared data store. On Friday, N

Re: preferred way to dereference a ref: outside or inside dosync?

On 22/11/13 08:18, Stefan Kamphausen wrote: How about (defn get-key-generator [] (let [i (atom 0)] (fn [] (swap! i inc (def generate-keys (get-key-generator)) nice one, much better than mine :) thanks Stefan... Jim -- -- You received this message because you are subscribed to the

Re: preferred way to dereference a ref: outside or inside dosync?

On Friday, November 22, 2013 12:29:25 AM UTC+1, Jim foo.bar wrote: > > apart from the generate-keys fn which is intentionally simplistic and > predictable so I can test somehow, I will admit that these are very good > points indeed. > How about (defn get-key-generator [] (let [i (atom 0)

Re: preferred way to dereference a ref: outside or inside dosync?

apart from the generate-keys fn which is intentionally simplistic and predictable so I can test somehow, I will admit that these are very good points indeed. Do at least consider the case where one thread already has a reference to an account another thread is closing. to me, this smells l

Re: preferred way to dereference a ref: outside or inside dosync?

generate-key is not thread-safe. Multiple callers might get the same id. It would probably be worthwhile to have your debit fn disallow a negative balance in some way. Maybe also don't allow closing an account unless it has zero balance. (Though the latter might require coordination between the "b

Re: preferred way to dereference a ref: outside or inside dosync?

My latest iteration has brought me to this: https://github.com/jimpil/bankio/blob/master/src/bankio/core.clj If anyone can think of a more evident and safe approach for demonstration purposes, by all means, shout out. After consulting the Clojure Programming book, I decided to use commute for

Re: preferred way to dereference a ref: outside or inside dosync?

On 21/11/13 13:19, John D. Hume wrote: If you want to demonstrate STM with the deposit-withdraw-transfer example, you definitely need a ref for each account. I'd suggest an atom for the account-num->balance-ref map ("the bank") and an atom for the account-num-generator, but you say coordinat

Re: preferred way to dereference a ref: outside or inside dosync?

If you want to demonstrate STM with the deposit-withdraw-transfer example, you definitely need a ref for each account. I'd suggest an atom for the account-num->balance-ref map ("the bank") and an atom for the account-num-generator, but you say coordination is necessary for opening and closing acco

Re: preferred way to dereference a ref: outside or inside dosync?

Hi, On Thursday, November 21, 2013 11:58:31 AM UTC+1, Jim foo.bar wrote: > > [...] 1. [...] Since there is a single > identity, perhaps STM is an overkill... > If I read your example correctly, it is not a typical use-case for STM. > > 2. can you ellaborate why you think this is debatable?

Re: preferred way to dereference a ref: outside or inside dosync?

also I forgot to add that having the bank in some reference type allows opening/closing new accounts, an operation that at least to me sounds like it needs coordination... So which way is preferred? map-ref that stores values, map that stores refs or map-ref that stores refs? Jim On 21/11/13

Re: preferred way to dereference a ref: outside or inside dosync?

Hi Stefan, thanks for your interest. let me explain further... 1. I did start with a design that involved a map (the bank) full of agents (accounts). Then I switched to a map full of atoms thinking that I don't really need asynchronous operations. I settled to the single ref approach because

Re: preferred way to dereference a ref: outside or inside dosync?

Hi, I may be missing something here, since this thread leaves me a bit confused. 1. Why are you using a Ref for the bank in the first place? It is a single identity and thus should be an atom, because you do not need to coordinate changes of at least two identities. If I am not mistaken, the

Re: preferred way to dereference a ref: outside or inside dosync?

Hi, Am Donnerstag, 21. November 2013 11:19:54 UTC+1 schrieb Jim foo.bar: > > On 20/11/13 19:36, juan.facorro wrote: > > The value for all refs whose value you don't actually modify inside a > transaction should be obtained through > ensure

Re: preferred way to dereference a ref: outside or inside dosync?

Hi Jim, the main differences are: deref inside transaction: returns the value of bank at the end of this transaction (unless you used commute somewhere). deref outside transaction: returns the value of bank at that time, other transaction may have committed meanwhile. Hope that helps. Meikel

Re: preferred way to dereference a ref: outside or inside dosync?

On 20/11/13 19:36, juan.facorro wrote: The value for all refs whose value you don't actually modify inside a transaction should be obtained through ensure if you want to make sure :P their value won't be changed by a different transactio

Re: preferred way to dereference a ref: outside or inside dosync?

Jim, The value for all refs whose value you don't actually modify inside a transaction should be obtained through ensure if you want to make sure :P their value won't be changed by a different transaction, that way you get a consistent v

Re: preferred way to dereference a ref: outside or inside dosync?

Hi, you would only want to use Refs when you need to update at least two of them with transaction semantics. When you need to read only one of them, you can just deref them any time you want, if you need a consistent snapshot of two refs, you need to read them inside a transaction, i.e. insi

Re: preferred way to dereference a ref: outside or inside dosync?

right the docs say: Within a transaction, returns the in-transaction-value of ref, else returns the most-recently-committed value of ref. so outside the transaction is probably what I want... Jim On 20/11/13 14:11, Jim - FooBar(); wrote: Hi all, I've been wondering about this lately and I'm

preferred way to dereference a ref: outside or inside dosync?

Hi all, I've been wondering about this lately and I'm not sure which approach to pick as both give the correct results (in my rudimentary tress-test). So as I understand it is generally suggested to have pure, testable functions that oter side-effecting functions rely on. like so for example: