Serialization bites again.

I’ve been back working on NHibernate.Remote for the last week since I finished some of the more urgent updates for the company where I’m working.  I’ve come to the sad realization that the path I’ve been treading with the initial NHibernate.Remote codebase just won’t cut it for several reasons.

1) NHibernate needs a session factory.  You just can’t operate remotely or locally without a session factory.  Initially my goal was to transfer the required factory information across the wire to the remote client. However this approach doesn’t work very well as SessionFactory information is deeply nested and not conducive to serialization.  So I’ve opted for the next best thing which is to create an identical session factory on both ends of the wire.  That way both the server and the client can be aware of Entities, Collections and Proxies.  The only thing that the remote session factory does not get is a connection string, so it cannot be used to open a direct database connection.  So far this has been working fairly well and has enabled me to get both Criteria queries and NHibernate.Linq queries working over the wire.

2) That was the good news, now for the bad news.  The remote client simply needs to be aware of the entities that it is holding.  That means that every time an entity or a collection comes in over the wire it needs to affect the persistence context.  If this can be implemented flushing the remote session will become much easier.  I thought that the ObjectGraphWalker that I had created would be up to this task but once again I appear to be mistaken.   One of the requirements  I need is that I need to be able to replace an entity as I walk the object graph.  Let me explain further.  In a local NHibernate session if you query an object, change some properties and then query that object again, NHibernate is smart enough to detect that it already has that entity and will return to you the original changed object.  I need to do that remotely, thus the requirement for substituting objects when I walk an incoming graph.  That is simply impractical with the way that the ObjectGraphWalker works.

So I’m back to needing custom access to the inner workings of a serializer. I’ve tried to hack my way into the NetDataContractSerializer but with little success.  Surely my requirement is neither original or unique and Microsoft would do well to provide more open access to their serialization techniques.  Most likely I’ll just have to use reflector to extract the functionality that I need.  Sigh.

Leave a Reply