Hi Hans,
I am currently doing all non IO work of a user command in a single generic function. This method is protected by a single global lock :around it. So I am using objects for application modules that handle user commands. OOP allows me to abstract common aspects of the modules.
I don't see the advantage of using a big transaction rather than a big lock. This big lock approach is very easy to grasp but It has two performance drawbacks: - It doesn't scale to multicores - When some commands require a long time, short commands suffer from high latency TBH I don't think these affect me much practically!
I think to solve the performance problems fine grain locks are used, they allow parallel execution but introduce those nasty problems like deadlocks.
Transactions then are introduced to lift the burden to think about the problems of fine grained locks and instead just define an "atomic" sequence of code. (In my opinion most database transactions still require too much thinking, for example whether to use "FOR UPDATE".)
Originaly I wanted to define the transactions at a more fine-grained level to avoid the performance problems. Due to the transaction implementation, it would only have bought me better latency, not scalability. At this level I would have needed generic transactions on the OOP "business level".
I have been thinking about transactions in the sense of Software transactional memory (STM). They would give a performance benefit, even for the coarse grain transactions. There are a lot of recent papers about efficient algorithms for STM, but I have not yet to seen an implementation in CL. While it would be feasible for Objects with AMOP, it seems very hard to track access to cons.
Thanks for the detailed responses! - Klaus
P.S. I also think that databases are nowadays clumsy for most applications. I have made bad experience with OO -> DB mappings, especially JPA.
Am Freitag, 22. Februar 2008 16:18:34 schrieb Hans Hübner:
[resending to bknr-devel]
I have given this more thought, and it appears that it would be possible to replace the existing macro based transaction execution environment by generic functions with a custom method combination. This certainly would make the BKNR code much prettier and simpler.
The question is: What would it buy the user? Certainly, it would make it possible to dispatch on argument types to run different code for different types. I am not sure that this would be so very useful, though. Transactions are not your average function, you are not going to invoke a large number of transaction one after the other to fullfill a user request or command.
Now, one could say that every function possibly is a transaction. The transaction monitor would only log the top level transaction invocation and process invocations of other transactions as standard function calls. This is what we currently do, albeit in a rather awkward and ugly form.
Still, I do not think that all functions should be transactions. Rather, transaction define the mutation points of an application, which makes them special and requires that they are well defined.
Now, this all does not mean that the transaction interface is perfect. There are two additions that I would consider worthwhile. One would be the possibility to specify action code to run within the global lock, but before actually mutating the persistent state of the system. This would be useful to check preconditions in a safe manner on preemptive multitasking systems. The other would be the possibility to declare an undo action which would help the application to roll back the persistent state to an earlier point in time.
Implementing transactions as generic functions would give us argument dispatch for free, which would certainly be nice. I managed to get away without being able to dispatch on transaction argument types or values so far, but that does not mean so much.
Your comments are greatly appreciated. Thanks.
-Hans _______________________________________________ bknr-devel mailing list bknr-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/bknr-devel