[resending to bknr-devel] Hi Klaus, 2008/2/22, Hans Hübner <hans@huebner.org>:
2008/2/22, Klaus Unger <UngerKlaus@gmx.de>:
- It is hard to map complex generic functions to transactions
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. Rather, one user command typically results in one transaction being executed, and in turn triggers a number of function calls from within the transaction body to accomplish whatever is needed. Thus, transactions are generally more coarse grained than functions. 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. Before going ahead with any of this, I would like to know what made you want generic functions as transactions. It could be that I'm missing something. Your comments are greatly appreciated. Thanks. -Hans