Comments for Clojure in a bank http://blog.malcolmsparks.com Applying a functional language to a large organisation Sun, 22 Apr 2012 21:44:48 +0000 hourly 1 http://wordpress.org/?v=3.3.2 Comment on Coding a transactional database using Clojure’s ‘reader literals’. by admin http://blog.malcolmsparks.com/?p=67#comment-91 admin Sun, 22 Apr 2012 21:44:48 +0000 http://blog.malcolmsparks.com/?p=67#comment-91 That's quite true, thanks for spotting that. You could extend the design with an 'await' on the agent. There's a lot more to make the database production-ready. The intention of the blog was to show a realistic example of using reader literals, a new feature which has just arrived in the latest version of Clojure. That’s quite true, thanks for spotting that.

You could extend the design with an ‘await’ on the agent. There’s a lot more to make the database production-ready. The intention of the blog was to show a realistic example of using reader literals, a new feature which has just arrived in the latest version of Clojure.

]]> Comment on Coding a transactional database using Clojure’s ‘reader literals’. by dsiegel http://blog.malcolmsparks.com/?p=67#comment-90 dsiegel Sun, 22 Apr 2012 21:42:02 +0000 http://blog.malcolmsparks.com/?p=67#comment-90 If I’m following along properly, the agent design isn’t actually Durable. Normally, a transactional database ensures that the log data has reached durable storage before permitting the caller of the transaction to proceed. The agent won’t write the log until an arbitrary amount of time after the transaction’s been committed. If the computer fails after the transaction completes, but before the agent writes the log, there'll be no record of the transaction. In the interim, the transaction caller could've done anything: report the result to an end-user, send it to another process, perform another transaction. In practice, the gap should be short, and the likelihood of a lost log record small -- but there's a hole here. If I’m following along properly, the agent design isn’t actually Durable.

Normally, a transactional database ensures that the log data has reached
durable storage before permitting the caller of the transaction to proceed.
The agent won’t write the log until an arbitrary amount of time after the
transaction’s been committed.

If the computer fails after the transaction completes, but before the
agent writes the log, there’ll be no record of the transaction.

In the interim, the transaction caller could’ve done anything:
report the result to an end-user, send it to another process,
perform another transaction.

In practice, the gap should be short, and the likelihood of a lost
log record small — but there’s a hole here.

]]> Comment on Coding a transactional database using Clojure’s ‘reader literals’. by admin http://blog.malcolmsparks.com/?p=67#comment-88 admin Thu, 19 Apr 2012 16:10:54 +0000 http://blog.malcolmsparks.com/?p=67#comment-88 I understand now, thanks Paul (and thanks Huey). Of course you're both right. I've re-jigged the TransactionLog to use an agent as you suggest and added some explanation in the text. I understand now, thanks Paul (and thanks Huey). Of course you’re both right. I’ve re-jigged the TransactionLog to use an agent as you suggest and added some explanation in the text.

]]> Comment on Coding a transactional database using Clojure’s ‘reader literals’. by Paul http://blog.malcolmsparks.com/?p=67#comment-87 Paul Thu, 19 Apr 2012 13:34:27 +0000 http://blog.malcolmsparks.com/?p=67#comment-87 Huey is saying that it's unsafe to call functions with side effects inside of dosync because they may be called more than once. http://clojure.org/refs So you shouldn't do I/O from within a dosync. Agents do not have this restriction, so they would be an option in this case. Huey is saying that it’s unsafe to call functions with side effects inside of dosync because they may be called more than once. http://clojure.org/refs So you shouldn’t do I/O from within a dosync.

Agents do not have this restriction, so they would be an option in this case.

]]> Comment on Coding a transactional database using Clojure’s ‘reader literals’. by admin http://blog.malcolmsparks.com/?p=67#comment-86 admin Thu, 19 Apr 2012 08:27:40 +0000 http://blog.malcolmsparks.com/?p=67#comment-86 Hi Huey - I don't quite understand your question but I'll do my best do answer anyway. The record inside the transaction is just some data for that transaction and a function which applies this data to an existing state. It doesn't stay around to be replayed though, once it is used (and logged) it is disposed of. It all takes place under Clojure's STM so you don't have to worry about co-ordinating transactions. Hi Huey – I don’t quite understand your question but I’ll do my best do answer anyway. The record inside the transaction is just some data for that transaction and a function which applies this data to an existing state. It doesn’t stay around to be replayed though, once it is used (and logged) it is disposed of. It all takes place under Clojure’s STM so you don’t have to worry about co-ordinating transactions.

]]> Comment on Coding a transactional database using Clojure’s ‘reader literals’. by Huey Petersen http://blog.malcolmsparks.com/?p=67#comment-85 Huey Petersen Thu, 19 Apr 2012 02:59:40 +0000 http://blog.malcolmsparks.com/?p=67#comment-85 Hello. I don't understand all of this but it looks awesome. One question though: isn't the record inside the transaction a side effect that could be replayed? Hello. I don’t understand all of this but it looks awesome. One question though: isn’t the record inside the transaction a side effect that could be replayed?

]]> Comment on Scalable sorting by Julian Birch http://blog.malcolmsparks.com/?p=42#comment-42 Julian Birch Mon, 07 Nov 2011 15:06:13 +0000 http://blog.malcolmsparks.com/?p=42#comment-42 I'm curious if you've had any experience of cascalog? It seems to be pretty much exactly made for scenarios like this. I’m curious if you’ve had any experience of cascalog? It seems to be pretty much exactly made for scenarios like this.

]]> Comment on Scalable sorting by Philipp Meier http://blog.malcolmsparks.com/?p=42#comment-38 Philipp Meier Thu, 03 Nov 2011 08:58:25 +0000 http://blog.malcolmsparks.com/?p=42#comment-38 The sort will likely fail if the collection containt :begin or :end. I suggest using instances of Object as markers as in <code> (let [begin-marker (Object.) end-market (Object.] ...) </code> The sort will likely fail if the collection containt :begin or :end. I suggest using instances of Object as markers as in

(let [begin-marker (Object.) end-market (Object.] ...)

]]> Comment on Configuring logging for Clojure applications by Malfario http://blog.malcolmsparks.com/?p=37#comment-13 Malfario Mon, 08 Aug 2011 09:02:09 +0000 http://blog.malcolmsparks.com/?p=37#comment-13 Sweet! Thank you! Sweet! Thank you!

]]> Comment on Configuring logging for Clojure applications by Al http://blog.malcolmsparks.com/?p=37#comment-12 Al Mon, 08 Aug 2011 04:12:04 +0000 http://blog.malcolmsparks.com/?p=37#comment-12 This looks really awesome, thank you for the hard work! I can't wait to start using this in my projects. This looks really awesome, thank you for the hard work! I can’t wait to start using this in my projects.

]]>