Sitecore Swamp

Dive in the Sitecore Swamp

NAVIGATION - SEARCH

C Sharp Refreshments - Assignment Operator (=)

Coding in C#, if the most frequently typed is ;, the second should =. There's something behind the most simple operator may not known for everyone. Let's start with a simple statement:

var b = 1;

This statement will assign the value 1 to b.

int b;

var a = b = 1;

This statement will assign the value to a and b. 

How about this one:

int b;

var a = ((b = 1) == 1);

Don't question it, this is a valid c# statement, and the value of a is True. Now you may get the sense that "b=1" not only assign the value, and itself has a value. In the official C# reference of = Operator

The assignment operator (=) stores the value of its right-hand operand in the storage location, property, or indexer denoted by its left-hand operand and returns the value as its result.

Cool, now we know this, so what?




The hiding gem - Sitecore Retryer [TBC]

If you have done long enough, you must noticed there's a retryer for Sitecore data connection to survive from failover for database calls. But can we reuse this retry mechanism for other purpose?

Let's have a peek:


 public interface IRetryable
  {
    /// <summary>Gets the interval.</summary>
    TimeSpan Interval { get; }

    /// <summary>Gets the repeat number.</summary>
    int RepeatNumber { get; }

    /// <summary>Executes the specified action.</summary>
    /// <typeparam name="T">Return type.</typeparam>
    /// <param name="action">The action.</param>
    /// <returns>T object.</returns>
    T Execute<T>(Func<T> action);

    /// <summary>Executes the specified action.</summary>
    /// <typeparam name="T">Return type.</typeparam>
    /// <param name="action">The action.</param>
    /// <param name="recover">The recover.</param>
    /// <returns>T object.</returns>
    T Execute<T>(Func<T> action, Action recover);

    /// <summary>Executes the no result.</summary>
    /// <param name="action">The action.</param>
    void ExecuteNoResult(Action action);

    /// <summary>Executes the no result.</summary>
    /// <param name="action">The action.</param>
    /// <param name="recover">The recover.</param>
    void ExecuteNoResult(Action action, Action recover);
  }

Sitecore has a retryer implemented already: Sitecore.Data.DataProviders.Retryer. It's actually quite good, and serves for generic purpose
- Execute: fire and forget
- Execute and return result (async)

Only one problem, there is only one configuration for this retryer, and you have to share the same with other retryer uses. This is not good.
<!--
RETRYER When enabled, the Retryer resends failed database requests a specified number of times. For example, this is useful if you configure a Sitecore instance to support hot failover for database calls. Default value: disabled="true"
-->
<retryer disabled="true" type="Sitecore.Data.DataProviders.Retryer, Sitecore.Kernel">
<param desc="Number of tries">6</param>
<param desc="Interval between tries">00:00:00.500</param>
<param desc="Log each exception (should be used for debug only)">true</param>
</retryer>

Let's see what we can do.

Factory.GetRetryer() is the static method to get the retryer with the configuration above. How about create another method to allow Factory.GetRetryer(string configName) to use different configuration. 

TBC