Quick comments on the transaction discussions: 1) There are basically two models of persistent objects in lisp: a load/store model and an always-persistent model. Weblocks presumes the former making adaptation of the always-persistent to Weblocks a bit challenging. If you are using Rucksack, which I believe is of the latter variety you might look at the automatic proxy-class functionality in Elephant which hooks into Weblocks to allow standard instances to be created that are converted into persistent objects when persist-object is called. It auto-creates these proxy classes so is pretty much invisible to the user. I haven't looked at the suggested improvements yet to see if they are able to do-away with this.
2) Elephant's current transaction model utilizes a dynamic variable to ensure in-process thread isolation. Each thread gets it's own transaction ID on the first call to with-transaction and this is shared among all subsidiary calls. This *transaction* variable can also store multiple transaction handles to support concurrent transactions on multiple independent stores for activities like migration when we have two transactions running concurrently. This model would have to be changed, or only simple use-cases supported, to fit into the independent start, commit, abort model used in Weblocks. If there is a cleaner way to do thread isolation I'm happy to implement it in Elephant and make any appropriate changes to Weblocks. Ian On Dec 26, 2008, at 4:51 PM, Stephen Compall wrote: > > helmut-vFAe+i1/wJJY/zfsw0qs4Ztpy8Vr/[email protected] writes: >> In Rucksack e.g., the begin-transaction return a transaction, which >> is used >> by commit and rollback. If a store is opened when the application >> starts, >> weblocks api allows only one active transaction per store, as store >> is >> the only parameter. > > Look at svg's weblocks-clsql changes. > >> It would be nice, to add the transaction as a parameter to commit and >> rollback, and as the return value of begin-transaction. > > I think this is a detail that should be handled by the store backend > using repeatable per-thread pools, not expanding the API for something > that most backends won't use. If you don't want to do this, you can > always save it yourself by answering T from use-dynamic-transaction-p > and implementing dynamic-transaction directly. > >> And perhaps a with-transaction macro for convenience. > > A webapp oughtn't ever use this. If you really need it, muffle > warnings > and call dynamic-transaction. > >> B) The persist-object is called with an instance, >> which should be made persistent. If the >> make-instance could be done in the persist-object method, >> this would save copying and code (at least in rucksack :-) > > Except that we always make the instance way before persisting it. > I've > found that to be so even when calling persist-object myself. Can you > show me why this would make store usage simpler? > > -- > I write stuff at http://failex.blogspot.com/ now. But the post > formatter and themes are terrible for sharing code, the primary > content, so it might go away sooner or later. > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "weblocks" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/weblocks?hl=en -~----------~----~----~----~------~----~------~--~---
