It's really easy to understand, and there is generally good tooling around dbs so people can use their existing tools to inspect saga state.
Admittedly, I have not explored the PHT/DHT stuff at all, since I simply converted an existing saga persister from an NSB project to RSB. I will spend some time with them this evening. My opinion may very well change! On Sat, Sep 5, 2009 at 4:34 PM, Ayende Rahien <[email protected]> wrote: > What are the advantages of that vs. using PHT/DHT? > > > On Sat, Sep 5, 2009 at 10:05 PM, Tyler Burd <[email protected]> wrote: > >> I completely agree that an NH dependency would be bad. I think a vanilla >> ADO persister would be a good thing to include. >> >> NSB used to have the DbBlobSagaPersister. It would be nice if there was >> something similar in RSB, but using an NTEXT field and the message >> serializer instead of binary serialization. >> >> >> On Sat, Sep 5, 2009 at 4:00 AM, Ayende Rahien <[email protected]> wrote: >> >>> Jason,Because they brought a lot of complexity to the table. >>> I actually think that the local DHT + optimistic is something that I >>> would like to end up with. >>> We can specify a local, self deployed, version for development, and scale >>> up for a remote one for farm scenario and a full DHT cluster for >>> reliability. >>> >>> On Fri, Sep 4, 2009 at 11:54 PM, Jason Meckley >>> <[email protected]>wrote: >>> >>>> >>>> I dug into the code and this finally clicked and I understand the >>>> problem of balancing configuration & extensibility. >>>> I spend most of my time in the previous revision since it's all in >>>> tack. >>>> in looking through it I can understand why you want to re-design how >>>> DHT works. Why remove the persister strategies and local DHT Client >>>> though? that all seems to work without issue. >>>> >>>> I think a db persister would be straight forward. were talking about a >>>> single table with 6 columns. wrap ADO.Net with a simple facade and >>>> call it a day. you could add a deploy action to build the schema. >>>> have it pull from the config file and add the table under another >>>> schema. similar to Rhino.Security. >>>> >>>> tyler i would be interested in your database implementation. for my >>>> immediate need I ported Local DHT Client and OptimisticStatePersister >>>> to my project to work against the latest RSB build. >>>> >>>> On Sep 3, 9:36 am, 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 -~----------~----~----~----~------~----~------~--~---
