The problem is that then you introduce a dependency on NHibernate.Not a biggie, but I have a fondness for zero dependencies here, just plug & go.
On Thu, Sep 3, 2009 at 4:36 PM, Tyler Burd <[email protected]> wrote: > I'm currently using a custom saga persister that I'd be happy to share, but > it uses NH and I doubt you want to make that a dependency of RSB. I found > it was simple to write (5 minutes), simple to understand, and it just > works. I didn't need *extreme* throughput, though, and I expect that's the > case for the vast majority of projects, so my vote is +1 for a simple db > persister. It's still going to be a hell of a lot more scalable than a > traditional thread hungry ASP NET app. > > -tyler > > > On Wed, Sep 2, 2009 at 4:43 PM, Ayende Rahien <[email protected]> wrote: > >> Right now I am working on the ESB parts of the port, and I am thinking >> hard again about what should and shouldn't be in there.On the one hand, >> one of the major reasons that I created RSB is that I wanted to make >> something that is developer friendly and easy to get started. >> On the other hand, there are some things where we do want to provide >> extensibility and customization for the users. >> For the most part, I think we managed to do that by using the container in >> some clever ways, but with the DHT saga storage I think I really messed it >> up. >> It is complex, both to set it up and to make use of it and to understand >> how it works. >> I have tentatively removed it from the project. >> I would like to provide a saga storage that is easy to use and fit the >> bill for most of the operations that you need, without bringing undue burden >> for the administrator or developer. >> >> Last week I had several discussions with Udi about that, and he pointed >> out that the most commonly used and easiest to reason about is a locked saga >> state. That is, during the execution of a transaction, the state of the saga >> is locked. A common example would be using a DB to handle that while using >> serializable transactions. >> >> I still want to enable the "let us just use this" mode, and I still want >> to avoid dependencies on infrastructure that isn't xcopy deployable. >> We can support this easily if we will utilize only the PHT. But that will >> work for local mode only. We can make use of the DHT, but then we need to >> provide a solution for farm wide locking. A lot of the design behind the DHT >> is based on always on system, because I have a requirement to keep the >> system going while nodes are coming and going. Locking is... interesting in >> this scenario. I would love to hear options about that. >> >> Or, we could just provide a simple DB saga state and let the DB handle >> that and clustering to handle fail over. >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Rhino Tools Dev" 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/rhino-tools-dev?hl=en -~----------~----~----~----~------~----~------~--~---
