Something causing serialization?

Something causing serialization?

Old forum URL: forums.lhotka.net/forums/t/5130.aspx


ajj3085 posted on Monday, July 21, 2008

Hi,

I have a winforms app, using csla 3.5.  I've been updating to the new features of Csla and starting replacing my dal with linq.  One user is getting an odd error I can't reproduce, and I don't think she's getting it all the time.

I have a process which runs on a background thread to save some data (not the main BO.. other BOs).  Sometimes I'm getting an error that one of my DAL objects couldn't be serialized, and it shouldn't be... everything data access wise should be happing in the remote dataportal, and it looks like my code is doing just that.  Still, the error persists.

I had a similar issue with another user; same DAL object, but that user was directly editing one of the BO's in question (as opposed to indirectly because of a service layer I have, which is was the first user is doing).  The solution for him was to uninstall my application and re-install it.  It's been fine since.

The same hasn't worked for this other user.. but she has four seperate installs of my application (each install is a branded version for different companies). 

I was wondering if anyone had things expected wanting to serialize in the remote dataportal when it wasn't needed.  Perhaps I just need to uninstall all instances... but I can't do that just yet.

Thanks
Andy

RockfordLhotka replied on Monday, July 21, 2008

There are a limited number of things that can cause serialization. Here are some:

  1. Calling DataPortal.Update() with AutoCloneOnUpdate turned on (it is on by default in 3.5)
  2. Calling Clone()
  3. Transitioning a call from one machine to another
  4. Transitioning a call from one AppDomain to another
  5. Transitioning a call from one context to another

Of course 1 and 2 will only serialize the objects flowing through the data portal or clone operation - your business objects. They would only serialize your DAL object if you somehow stored the DAL object in an object-level instance field.

3-5 are less common, but can occur if you trigger such a transition.

3 occurs inside the data portal, but that's really a variation on 1 in that case. And you'd know if you were calling Remoting/WCF/whatever yourself.

4 can sneak up on you when using something like nunit, but in your own code I think you'd know if you created your own AppDomain.

5 is most rare, because you need to create context-bound objects (MarshalByRefObject is most common). One way this can happen is if you use an AOP framework, because a lot of them use context-bound objects as a hack to trigger pre- and post-call aspects. You'd know if you were using an AOP framework, or if you'd inherited from MRBO I think.

ajj3085 replied on Monday, July 21, 2008

It sounds like it could only be option 3 causing this.

I do have a portion of code that runs in the data portal that calls another piece of code which does a DataPortal.Fetch... but if it's already remoted then I would think a local data portal would be used, and it doesn't sound like the local one would cause serialization.

RockfordLhotka replied on Monday, July 21, 2008

Hmm. DataPortal.Fetch() should never cause serialization in local mode, only DataPortal.Update() would do that.

 

Rocky

 

Copyright (c) Marimer LLC