Fwd: [bknr-devel] bknr.indices, the slot NIL is missing from the object

[Hans Hübner]

[resending to bknr-devel]

Hi Klaus,


 2008/2/22, Hans Hübner <hans at huebner.org>:

>  2008/2/22, Klaus Unger <UngerKlaus at 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