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

[Klaus Unger]

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 at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/bknr-devel