Well, the thing is that the majority of the changes aren't to already existing code; it was barely changed (besides re-ordering through re-sharper). 1000+ lines is the FileTransaction doing p/invoke into kernel32.dll and methods when for example deleting recursively with TxF. Changes to the core files, TransactionInterceptor is adding new meta-data and also when inspecting, a new list with methodinfos for those methods wanting the tx injected.
It seems to be working OK and I got tests for it and they pass. I haven't been able to find any bugs now for over a month, so I'm fairly confident it works. Now, I don't plan on releasing just from that patch, but I kind of need it as a baseline so I can add some other unit tests and have someone running Mono and XP test it: the patch is tested on Vista but not on any other Windows, so this is what I need help with; if people could apply the patch and just try it, it would be nice (since I have changed a lot of castle's code locally). So, I feel you can apply the patch and run the tests. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of hammett Sent: den 16 juni 2009 02:30 To: [email protected] Subject: Re: Castle Transactions I checked the list and seems very cool. It will, though, de-stabilize what we have, right? You may want to consider release what we have first, then make such big changes. If you're confident the changes are stable, then let us know too. On Mon, Jun 15, 2009 at 1:37 PM, Henrik Feldt<[email protected]> wrote: > > Can I get a vote on whether the _functionality_ described below is to > be added, from the rest of the people on this list, please? [+1, > -1].Choice(); > > Then, I would appreciate something on the _actual_ implemented > functionality as well. [+1, -1].Choice(); > > Either we do it or we don't do it. Very simple. Either way we should > release v.1.x or v.2.0 of the service and stop delaying. I thought I > was going to do PM on this project so we can start releasing stuff? > > Cheers > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Henrik > Feldt > Sent: den 9 juni 2009 07:15 > To: [email protected] > Subject: RE: Castle Transactions > > > Alright, thanks for answering, it helps planning. > > I don't have time right now to do a long write-up I'm afraid, so it > would be better to go by unit tests, in terms of what it does, > however, here are the major features of the changes: > > * Introducing IMapPath to bridge gap between desktop and web > development with the same tools, mostly used when referring to the > same folder as is the "current folder": "~/plugins" for example. > * Introducing IFileAdapter and IDictionaryAdapter to wrap either Win32 > API calls xor static File class calls in System.IO, or on linux > possible calls to whatever DTC or file transaction APIs are available. > Injected with dependency injection. > * Introducing FileTransaction, plus its resource adapter with many > lines of code, because p/invoke is lengthier to write code for. > Contains most logic for many of the methods of the static class File, but implemented with FtX. > - FtX is used by Windows Update: " There are three core > features in Windows Vista and Windows Server "Longhorn" that now make > use of Transactional NTFS: Windows Update, System Restore, and Task > Scheduler. All of these use TxF to write files to the file system > within the scope of a transaction in order to handle rollback/commit > in case of any exceptions, such as a system reboot due to a loss of power." > http://msdn.microsoft.com/en-us/magazine/cc163388.aspx as you probably > already know. > - I personally haven't been able to find a wrapper for C# for > this, so I believe it's something good to add to the project. > - I have tested this class extensively on my own projects so > I'm pretty confident it works. If it doesn't, I'd like that input and > is possible a repro. > - The class inherits things IFileTransaction, but doesn't > implement everything; relies on explicit interface implementations in > order to specify similar operations of files and directories which are > both file system objects (i-nodes) > - By integrating with PathUtil which I built, some bugs with > finding the root of a path in .net are corrected, by the use of regular expressions. > I think I put the test-case for it in the patch, but this as well has > been tested a lot. > - Supports UNC naming of paths, but this hasn't been > extensively quality assured, so there may be cases where it's relying > on some part of .Net's IO namespace which doesn't support it. > * Introducing SafeTxHandle which by its inheritance chain extends > CriticalFinalizerObject, and hence is a good way of improving > reliability in the code. Since it's a safe handle, the finalizer is > guaranteed to run and hence won't leak resources. Also, things > inheriting this object will be weakly ordered to go before objects not > inheriting it when GCed. See this article for more info: > http://msdn.microsoft.com/en-us/magazine/dd419661.aspx > * The Transaction Integration infrastructure (interceptor) has been > extended to allow you to inject transactions into the method using it > with the InjectTransactionAttribute class. > > So this is it. I've also personally integrated this with the > NHibernateIntegration project so that persisted configurations are > transacted; obviously very easy; just create a delegating class and > slap [Transaction] on top of them, and redirect all File. and > Directory. calls to use IFileAdapter and IDirectoryAdapter, and you're done. > > I can't fathom a "small code spike" for this. It's either or; > implement a part of it with transactions and ALL of your file accesses > need to use the same transactions of by definition of isolation in > ACID, you won't be able to see the changes to the file system. (!) > > So this is it, not much more, I'm afraid. I hope you have gained an > insight into the patch and can make a decision from this, or otherwise > will let me know! > > Regards, > Henrik > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of hammett > Sent: den 9 juni 2009 00:53 > To: [email protected] > Subject: Re: Castle Transactions > > > I took a peak at the patch. Seems very promising! > But I agree with Roelof, big changes should happen in small steps. > > Thanks > > On Mon, Jun 8, 2009 at 11:37 AM, Roelof Blom<[email protected]> wrote: >> Henrik, >> >> I've seen your patch and was quite overwhelmed by the sheer amount of >> changes, pPerhaps you should start by explaining what your patch is >> supposed to do; you sent a 4000+ line patch file out of the blue >> stating 'AutomaticTransactionManagement needs to be updated with a >> bit of code [...]'. Start a discussion to gain feedback, supply a >> small code spike, try to gather interest for your feature on the list >> and/or > UserVoice. >> >> A sample spec like this >> http://using.castleproject.org/display/AR/NHEventListenerSpecs would >> also be a good thing for such a complex feature you are proposing. >> >> -- Roelof. >> >> >> >> On Mon, Jun 8, 2009 at 7:46 PM, Henrik Feldt <[email protected]> wrote: >>> >>> However, considering I can’t commit nor get anyone answering my >>> e-mails about this (the patch I sent + testing it out), how am I >>> supposed to get somewhere with this? If I’m supposedly in charge of >>> the transaction project, surely I could have access to that specific >>> part of the trunk or otherwise have someone actually commit my changes? >>> >>> >>> >>> From: [email protected] >>> [mailto:[email protected]] On Behalf Of Henrik >>> Feldt >>> Sent: den 31 maj 2009 15:22 >>> To: [email protected] >>> Subject: RE: Castle Transactions >>> >>> >>> >>> Man, you’re great to have when I hadn’t slept for way too long! J >>> >>> >>> >>> From: [email protected] >>> [mailto:[email protected]] On Behalf Of Roelof >>> Blom >>> Sent: den 31 maj 2009 07:52 >>> To: [email protected] >>> Subject: Re: Castle Transactions >>> >>> >>> >>> Check Environment.OSVersion.Platform? >>> >>> On Sun, May 31, 2009 at 2:00 AM, Henrik Feldt <[email protected]> wrote: >>> >>> If there is something similar for Mono, that would be great, because >>> we wouldn’t need platform-specific compiles… >>> >>> >>> >>> Regards, >>> >>> Henrik >>> >>> >>> >>> From: [email protected] >>> [mailto:[email protected]] On Behalf Of Roelof >>> Blom >>> Sent: den 30 maj 2009 23:51 >>> >>> To: [email protected] >>> Subject: Re: Castle Transactions >>> >>> >>> >>> You need to check at runtime, don't you? Use something like this >>> >>> if(Environment.OSVersion.Version.Major > 5) { /* vista and above */ >>> } >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Sun, May 31, 2009 at 12:16 AM, Henrik Feldt <[email protected]> wrote: >>> >>> Actually, no, because it’s built on the vista kernel and hence >>> supports TxF and TxR, but I’m not sure what to do about Win5 and >>> lesser. Is there some sort of compile-constant for it? This is the >>> way it currently looks, and I think I need something pre-vista and >>> not > just MONO: >>> >>> >>> >>> Example: >>> >>> /// <summary> >>> >>> /// Deletes a folder recursively. >>> >>> /// </summary> >>> >>> /// <param name="path"></param> >>> >>> public void Delete(string path) >>> >>> { >>> >>> AssertAllowed(path); >>> >>> #if !MONO >>> >>> IFileTransaction tx; >>> >>> if (HasTransaction(out tx)) >>> >>> { >>> >>> ((IDirectoryAdapter)tx).Delete(path); >>> >>> return; >>> >>> } >>> >>> #endif >>> >>> Directory.Delete(path); >>> >>> } >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> From: [email protected] >>> [mailto:[email protected]] On Behalf Of Roelof >>> Blom >>> Sent: den 30 maj 2009 20:15 >>> >>> To: [email protected] >>> Subject: Re: Castle Transactions >>> >>> >>> >>> Non-Vista would also be Windows 7 RC? >>> >>> On Sat, May 30, 2009 at 9:03 PM, Henrik Feldt <[email protected]> wrote: >>> >>> Cool, np. I’ve changed it. Quite ready to commit now. I guess it’s >>> patching that’s it for me, right… >>> >>> >>> >>> I need someone to test on non-vista systems and mono to make sure >>> the new code paths don’t become activated. Volunteers? >>> >>> >>> >>> Cheers, >>> >>> Henke >>> >>> >>> >>> From: [email protected] >>> [mailto:[email protected]] On Behalf Of Jonathon >>> Rossi >>> Sent: den 30 maj 2009 16:18 >>> To: [email protected] >>> Subject: Re: Castle Transactions >>> >>> >>> >>> Shouldn't it be using Castle's ILogger in Castle.Core, which >>> indirectly can depend on log4net. >>> >>> On Sat, May 30, 2009 at 8:34 PM, Henrik Feldt <[email protected]> wrote: >>> >>> Can we make it depend on log4net? >>> >>> >>> >>> >>> >>> >>> -- >>> Jono >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >> >> > >> > > > > -- > Cheers, > hammett > http://hammett.castleproject.org/ > > > > > > > > -- Cheers, hammett http://hammett.castleproject.org/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Castle Project Development List" 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/castle-project-devel?hl=en -~----------~----~----~----~------~----~------~--~---
