Once you are inside DataPortal_XXX calls, you are executing on the
server. At that point you should not use DataPortal.Execute inside of if,
but instead create DBCommand object directly.
Sergey Barskiy
Senior Consultant
office: 678.405.0687 |
mobile: 404.388.1899
Microsoft Worldwide Partner of the Year | Custom
Development Solutions, Technical Innovation
From: macux
[mailto:cslanet@lhotka.net]
Sent: Thursday, April 10, 2008 8:07 AM
To: Sergey Barskiy
Subject: [CSLA .NET] Issues calling DataPortal.Execute on server?
Is it likely that I will have any issues in the following
scenario:
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 re mote 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.
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).
Copyright (c) Marimer LLC