Ayende @ Rahien

Hi!
My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:

ayende@ayende.com

+972 52-548-6969

, @ Q c

Posts: 5,972 | Comments: 44,508

filter by tags archive

Midbook pattern crisis: Do NOT reach for that pattern


From a question in the mailing list:

How do you do to "rollback" an entity state supposing the following scenario.

public JsonResult Reschedule(string id, DateTime anotherDate)
{
            try
            {
                var dinner = session.Load<Dinner>(id);
                dinner.ChangeDate(anotherDate);
                schedulerService.Schedule(dinner); 

                return Json(new { Message = "Bon apetit!" });
            }
            catch (DinnerConcurrencyException ex) 
            {
                return Json(new { Message = ex.Message });
            }
}

// Base controller
protected void OnActionExecuted(ActionExecutedContext filterContext) 
{
      if(filterContext.Exception != null)
            return;
      session.SaveChanges();
}

The problem that I have is when the schedulerService throws a DinnerConcurrencyException, it is catched at the controller.

After all, the OnActionExecuted will call SaveChanges and persist the dinner with an invalid state.

The next post was:

I have already tried to use Memento Pattern like this:

try
{
    var dinner = session.Load<Dinner>(id);
    dinner.SaveState();
    dinner.ChangeDate(anotherDate);
    schedulerService.Schedule(dinner); 

    return Json(new { Message = "Bon apetit!" });
}
catch (DinnerConcurrencyException ex) 
{
    dinner = dinner.RestoreState();
    return Json(new { Message = ex.Message });
}

But didn't work, beacuse I think Raven has proxied my dinner instance.

And here is the Memento implementation:

[Serializable]
public abstract class Entity
{
    MemoryStream stream = new MemoryStream();

    public void SaveState()
    {
        new BinaryFormatter().Serialize(stream, this);
    }

    public T RestoreState<T>()
    {
        stream.Seek(0, SeekOrigin.Begin);
        object o = new BinaryFormatter().Deserialize(stream);
        stream.Close();

        return (T)o;
    }
}

You might notice that this create a new instance when you call RestoreState, and that has no impact whatsoever on the actual instance that is managed by RavenDB.

The suggested solution?

catch (DinnerConcurrencyException ex) 
{
    SkipCallingSaveChanges = true;
    return Json(new { Message = ex.Message });
}

No need for patterns here.


Comments

Dmitry

There is no Evict command in RavenDB?

Gene Hughson

"No need for patterns here."

Occam's Razor isn't a pattern? :-)

Ayende Rahien

Dmitry, session.Advanced.Evict

Stan

The whole problem starts when we try to hide session creation and commit somewhere in the controller's base class. What we try to save? Two lines of code (store.OpenSession() and session.SaveChanges()) for each action? And the price is the loss of control. As for me, there is no shame to open session right in your action. Do you fear that programmer will forgot to call save changes? That is his job and he payed for it. As Ayende sayed before, JFHCI.

Comment preview

Comments have been closed on this topic.

FUTURE POSTS

  1. Paying the rent online - 15 hours from now
  2. Reducing parsing costs in RavenDB - about one day from now

There are posts all the way to Aug 04, 2015

RECENT SERIES

  1. Production postmortem (5):
    29 Jul 2015 - The evil licensing code
  2. Career planning (6):
    24 Jul 2015 - The immortal choices aren't
  3. API Design (7):
    20 Jul 2015 - We’ll let the users sort it out
  4. What is new in RavenDB 3.5 (3):
    15 Jul 2015 - Exploring data in the dark
  5. The RavenDB Comic Strip (3):
    28 May 2015 - Part III – High availability & sleeping soundly
View all series

Syndication

Main feed Feed Stats
Comments feed   Comments Feed Stats