Suppressing AutoCloneOnUpdate when executing on LogicalExecutionLocations.Server?

Suppressing AutoCloneOnUpdate when executing on LogicalExecutionLocations.Server?

Old forum URL:

Miroslav Galajda posted on Wednesday, April 10, 2013

I'm playing with an idea that when executing something server-side (from logical point of view) I generally do not want and do not need to have csla to clone the objects. 

For example, you can have command doing some updates on a large set of business objects.

I have two main reasons for that:

  1. performance reasons
  2. NHibernate.NonUniqueObjectException - when using nhibernate as your database persistence layer. This happens when you get the business object and save the business object during the same nhibernate session. Most of nhibernate users should know what I'm talking about.

So, what do you think about this idea? Can I suppress the AutoCloneOnUpdate behavior when executing at server-side (logical location) by default.

It seems to me it should be always safe because the main reason for autoclone is to have separated object on the server from the client, because the server could change (and in most situations it does) the object while saving to DB (for example change timestamps, set id when inserting object) and when the transaction during that save fails it should leave the object at client intact.

I assume that server-side executions are always about doing some stuff that never wants to recover from "broken" object. Mostly you want to recover from that by rethrowing the exception that happend and having the client deal with that exception and reexecuting the server operation again.

JonnyBee replied on Wednesday, April 10, 2013


Are you using a N-Tier deployment with a remote DataPortal?

The AutoCloneOnUpdate is to make that you get the same behavior when running in-process (local dataportal) as you do when using a remote portal.
A remote portal will always return a new object from the server - but when your code runs in-process and AutoCloneOnUpdate is false - then your object structure would be as it was when the exception occured (= broken) and you can NOT call Save again on that object.

That is assuming that your save uses a transaction and rolled back in the database - but your object is NOT rolled back to it's initial state!!


Miroslav Galajda replied on Thursday, April 11, 2013


I'm using diffrent deployments in different solutions.

You have slightly missed what I really want to achieve. I'm aware of N-tier deployment and how the dataportal in that situation work. So I have proposed the idea if it is right or if I'm not wrong with that idea.

When you are logically on server and you are calling your business object to perform Save you don't need to do clones (AutoCloneOnUpdate = true), because you are already on server and you already have the clone on the server. And when you are on the server then calling dataportal on the server calls in most situations local dataportal (or if you have another remote portal then you get the clone but this is not the case you have to worry about).

So what do you think? Is it clearer now for you?

Miroslav Galajda replied on Friday, April 12, 2013

I'm providing code snippet from what I've done in Csla source code to realize and test the idea:

    /// <summary>
    /// Gets a value indicating whether objects should be
    /// automatically cloned by the data portal Update()
    /// method when using a local data portal configuration.
	/// Defaults to <c>true</c>.
    /// </summary>
    public static bool AutoCloneOnUpdate
        bool result = true;
		// Miroslav Galajda 10.04.2013 - when executing on server-side (from logical point of view) then clone is redundant
		if (LogicalExecutionLocation == LogicalExecutionLocations.Server && AutoCloneOnUpdateClientOnly)
			return false;
        string setting = ConfigurationManager.AppSettings["CslaAutoCloneOnUpdate"];
        if (!string.IsNullOrEmpty(setting))
          result = bool.Parse(setting);
        return result;

Where as you can see there is also way to have turn this behavior off through the AutoCloneOnUpdateClientOnly property (appSettings variable).

Miroslav Galajda replied on Tuesday, April 23, 2013

Does anyone has something against it or is there any pitfall?

Copyright (c) Marimer LLC