-
For performance tuning and general debugging I need detailed logging about every request made to the DataPortal from clients. Specifically I'm looking for the following: 1) The BO's class name and method 2) Fetch, Update, Create, Delete, Execute 3) Execution time of the call 4) Result (Success vs Failure) 5) The UserID (from the Principal object
-
That seems to fix it. I tried it in several situations, including with colliding hash keys, and it seems to work okay. Thanks!
-
The other thing I'll point out is that this happening " during app initialization (basically)" is a bit misleading. This conflict can occur whenever there is a MethodCache cache miss. So this can happen whenever any method is invoked for the first time (see line 61 in MethodCaller.cs). Actually, we have global non-thread safe dictionaries
-
I thought your solution might work at first, but I'm still seeing problems with it. The reason is that the Dictionary can be in the middle of being updated when a reader comes along to read the value. The problem is that Dictionary does not have any atomic methods at all. For example: class Program { public static IDictionary<int, int> dict
-
Line 229 in MethodCaller.cs defines the _memberCache as: private static readonly Dictionary<MethodCacheKey, DynamicMemberHandle> _memberCache = new Dictionary<MethodCacheKey, DynamicMemberHandle>(); I'd love to provide the actual code causing the error, but this is a bug that only happens in very specific situations. For instance, it
-
I've found a bug in the way the MethodInfo is cached in CSLA. I'm using the most recent release. The issue comes down to this code: The _methodCache in MethodCaller is not thread safe. This means that if one thread is making the first DataPortal call to an object while another thread is doing the same. One of the threads either hangs or we get
-
With our app we send a large amount of data across the wire via CSLA. It was our initial performance issues with the serializer that me looking into how to improve the serialization. I think what should be mentioned though, is that there is a "critical mass" of sorts where this new serializer begins to be a big improvement. In our app, we
-
That should work great, as long as ISerializationFormatter completely replaces the MobileFormatter. I had some issues modifying the older code, since the Silverlight code had direct references to MobileFormatter sprinkled through the code. As long as I can completely override that though (even in cases of cloning), these changes should work fine.
-
Recently one of our projects has had the need to send a large number of objects from Silverlight to .NET using CSLA. However we were having OutOfMemory Exceptions with the MobileFormatter. So about a week ago I sat down to try to improve the MobileFormatter a bit. For those who are unfamiliar with how the MobileFormatter works the process is as follows
-
So you're suggesting we throw out a 3 line fix for an exception simply because "it doesn't affect performance enough"....that's just sad.