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 -~----------~----~----~----~------~----~------~--~---
