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 accounts. What coordination do you have
in mind?
On Nov 21, 2013 5:27 AM, "Jim - FooBar();" <jimpil1...@gmail.com> wrote:
> 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 10:58, Jim - FooBar(); wrote:
>
>> 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 it seemed like an overkill to have all these refs inside.
>> Your comment however does make sense...Since there is a single identity,
>> perhaps STM is an overkill...
>>
>> 2. can you ellaborate why you think this is debatable? All the
>> ref-managing fns return the in-transaction value of the ref (i.e. 'alter').
>> My problem was with 'doseq' which returns nil so I followed the general
>> approach of returning the in-transaction value of the ref after it commits.
>>
>> 3. As I understand it these 2 transactions will be composed/merged into a
>> single transaction. Again, originally I had a bare 'alter' (no dosync) on
>> the private fn transfer1 simply because it is hidden and not supposed to be
>> used...think of it as a helper fn for 'transfer'. but then I read somewhere
>> that transaction can be nested without a problem so I thought it is safer
>> to include 'dosync' in tranfer1 as well...
>>
>> I'm not getting you wrong, don't worry...this is the reason I started
>> this thread - need some answers /feedback :)
>>
>> Jim
>>
>>
>> On 21/11/13 10:42, Stefan Kamphausen wrote:
>>
>>> 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 generic bank transfer example is to have a Ref
>>> for each of the accounts and to make sure, that there is never a state of
>>> the world in which the money is missing or is available twice.
>>>
>>> 2. "Even our side-effecting fns return something (per alter) which is
>>> good." -> That seems debatable to me.
>>>
>>> 3. Why do you nest transactions on the same Ref in transfer1 and
>>> transfer?
>>>
>>> Don't get me wrong, what you're doing may be fine. In that case, I just
>>> don't get it. Which, in turn, may be a relevant feedback to you, since
>>> this is to be educational :-)
>>>
>>>
>>> Kind regards,
>>> Stefan
>>>
>>>
>>> --
>>> --
>>> 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
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojure+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>
>>
> --
> --
> 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
> --- You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
--
--
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
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
