The reason we moved to the NHibernateSagaPersister is that we could use it to automatically generate a schema for the user's saga objects including the appropriate indexable columns. This means users don't need to understand more than to point it at a given database and it'll install and go.
Hope that makes sense. -- Udi Dahan On Sep 5, 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 -~----------~----~----~----~------~----~------~--~---
