Issues calling DataPortal.Execute on server?

macux posted on Thursday, April 10, 2008

Is it likely that I will have any issues in the following scenario:

• UI calls businessObject.Save() on a new business object
  
• CSLA calls DataPortal.Update... and in turn DataPortal_Insert on the busines object
  
• Business object does various things including running a command object using DataPortal.Execute

The last step is all done within a single transaction which is started and completed with the DataPortal_Insert method. This is obviously vital to the system. Clearly this won't have any issues if the code is being run on one machine but is it likely to cause issues if a non-local proxy is in use?

When the DataPortal.Execute is called for the command, the framework will check the config again and use Activator.GetObject to create a remoting proxy. This however will be on the local machine now as the original DataPortal call would have moved everything to the remote server. Presumably no serialization will take place in calls for the command object? The transaction is passed as a property on the command so this wouldn't serialize.

How about issues with non-local proxies other than the remoting proxy?

Any comments appreciated.

sergeyb replied on Thursday, April 10, 2008

macux replied on Thursday, April 10, 2008

Thanks for the reply. However, the reason I'm doing this is that I'm re-using a method on another class which gets used on its own from the client as well. Looking at the CSLA source it doesn't look like it will cause me an issue doing it like that, unless there is some serialization involved or unless I'm missing something.

It seems to me all the framework is doing is going through some hoops to call DataPortal_Insert or whatever on the business object. One of the big benefits of the framework is having config file based control over where the code executes and my approach above is in keeping with this, i.e. I want to be able to execute the same method and have it work regardless of location.

RockfordLhotka replied on Thursday, April 10, 2008

macux:

When the DataPortal.Execute is called for the command, the framework will check the config again and use Activator.GetObject to create a remoting proxy. This however will be on the local machine now as the original DataPortal call would have moved everything to the remote server. Presumably no serialization will take place in calls for the command object? The transaction is passed as a property on the command so this wouldn't serialize.

If your server is properly configured this WILL NOT HAPPEN.

The server should NOT have the CslaDataPortalProxy item in its config file. This means the server's data portal will run in "local mode" - which means all data portal calls will run on the server - which is what you want.

I constantly have objects call other objects within the DataPortal_XYZ methods. All those calls run in the same server process, in the same transactional context. The data portal is designed to support this scenario - as long as you configure the server so its data portal runs in local mode (which is the default, and is what you should do).

The only thing you need to watch for is opening extra database connections. You don't want each root object opening its own database connection (probably) because that will cause the DTC to be used - incurring a performance hit. The Csla.Data.ConnectionManager and Csla.Data.ContextManager classes in CSLA 3.5 are intended to help you avoid this problem without extra work. They reuse an open connection if it exists, or open a connection if there isn't one already (and then that one is reused going forward).

macux replied on Friday, April 11, 2008

OK, that's simple now you've said it! Obviously we have completely separate control over the server install. The connection issue is OK as there will only ever be one opened for this process, and one transaction, we have a layer on top of the framework which sorts this out. I appreciate the reply.