ok, can actually sign in now..... confirmation was being spam-filtered by gmail.
So, where would you like me to put this wiki page? On Sat, Nov 27, 2010 at 7:09 PM, Aaron Boxer <[email protected]> wrote: > well, sadly I am not getting my confirmation email after trying to > join the nhforge wiki. > Any ideas? > > > On Sat, Nov 27, 2010 at 9:14 AM, Fabio Maulo <[email protected]> wrote: >> Can you write a Wiki on nhforge.org about your provider ? >> >> On Sat, Nov 27, 2010 at 10:07 AM, Aaron Boxer <[email protected]> wrote: >>> >>> Fatal, >>> >>> Glad to hear you sorted that out. >>> >>> If you are looking into distributed caches for NH, >>> you should check out my provider for Redis: >>> https://github.com/boxerab/NHRedis >>> >>> Redis is a blazing fast, distributed cache that supports lists, >>> hashes, and transactional >>> semantics. >>> >>> NHRedis does support distributed hard locks. Also, I am planning to >>> write a copy on write >>> concurrency strategy for NH, based on NHRedis, which will remove the >>> locks on gets, >>> and dramatically simplify the design. >>> >>> Cheers, >>> Jorge >>> >>> >>> On Fri, Nov 26, 2010 at 10:24 PM, Fatal <[email protected]> wrote: >>> > hi Jorge, >>> > >>> > Yes, I am using the read-write concurrency strategy. It turns out that >>> > the code from that stackoverflow link didnt work too well wrt locking/ >>> > unlocking. It basically wasnt working properly and the exceptions were >>> > being swallowed without any form of logging. >>> > >>> > As it turns out, NH is only calling lock once on the ICache >>> > implementation for each unlock. >>> > >>> > I did some reading on the velocity today and have updated the >>> > NH.Velocity cache to work a little better; patch contributed as >>> > NHCH-31 (http://216.121.112.228/browse/NHCH-31). >>> > >>> > cheers >>> > Fatal >>> > >>> > On Nov 27, 3:39 am, Aaron Boxer <[email protected]> wrote: >>> >> Hi Fatal, >>> >> >>> >> I take it you are using read-write concurrency strategy. >>> >> >>> >> I've delved into the caching code a little, and from what I can >>> >> gather, multiple Lock >>> >> calls simply increment the lock count on the same soft lock object. The >>> >> lock >>> >> handle should not be changing. >>> >> >>> >> I'm curious to know how you work this one out, as I am developing a new >>> >> cache strategy class for read committed and repeatable read isolation. >>> >> >>> >> Cheers, >>> >> Jorge >>> >> >>> >> On Fri, Nov 26, 2010 at 2:37 AM, Fatal <[email protected]> wrote: >>> >> > hi all, >>> >> >>> >> > I've begun using the NHibernate.Caches.Velocity implementation today. >>> >> > I'm updating the code to be compatible with the newer version (aka >>> >> > AppFabric Caching Services). To do so, I used the VelocityClient code >>> >> > from this stackoverflow question as a >>> >> > basis:http://stackoverflow.com/questions/3233792 >>> >> >>> >> > I seem to be having some trouble with errors coming out of the >>> >> > locking >>> >> > implementation and I just wanted to clarify the behaviour of >>> >> > nhibernate caching as it relates to locking. >>> >> >>> >> > What i'm seeing is that NHibernate is calling Lock() several times >>> >> > for >>> >> > the same key before it calls Unlock(). With the implementation of the >>> >> > code from the link above, this causes exceptions because its trying >>> >> > to >>> >> > add a different lock handle with same key to a dictionary (i.e. >>> >> > because it is already locked) >>> >> >>> >> > None of the the NHContrib caches apart from this one seem to >>> >> > implement >>> >> > locking yet so i'm curious as to whether its a bug with NHibernate or >>> >> > if its intended behaviour and it is expected that locking >>> >> > implementations ignore the case where the item is already locked. >>> >> >>> >> > Is anybody able to provide any clarity around this locking >>> >> > functionality? >>> >> >>> >> > thanks, >>> >> > Fatal >>> >> >>> >> > -- >>> >> > You received this message because you are subscribed to the Google >>> >> > Groups "NHibernate Contrib - Development Group" 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 >>> >> > athttp://groups.google.com/group/nhcdevs?hl=en. >>> > >>> > -- >>> > You received this message because you are subscribed to the Google >>> > Groups "NHibernate Contrib - Development Group" 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/nhcdevs?hl=en. >>> > >>> > >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "NHibernate Contrib - Development Group" 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/nhcdevs?hl=en. >>> >> >> >> >> -- >> Fabio Maulo >> >> -- >> You received this message because you are subscribed to the Google Groups >> "NHibernate Contrib - Development Group" 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/nhcdevs?hl=en. >> > -- You received this message because you are subscribed to the Google Groups "NHibernate Contrib - Development Group" 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/nhcdevs?hl=en.
