I think that dates back many years - to before our use of Entity Framework, when we were experimenting with NHibernate . The idea was that Flush would force things to be written to the database, even though you hadn't committed the transaction
(i.e. could still be rolled back again), such that they could be read by another method within the same transaction.

To be honest, we're not sure what effect, if any, Flush has when operating with EF - because EF handles all the flushing and there are fewer opporunities (or needs) to intervene. I'll raise a ticket to investigate this and, if that hypothesis
is correct, we'll mark Flush as Obsolete.

That's the thing. A second call throws an error saying there is no transaction to end.
So does the first if I don't explicitly start one.

But now I am confused, as the transaction has not yet been committed to the DB right before the end of the controller method.
So if it automatically starts a transaction, why is it not there for me to explicitly end. That was my whole problem to start with.

If I can jump in... if the NO MVC architecture hasn't changed from the old NOF/Java days, then the way this may be working is that the framework collates all the changes during the action (in the UpdateNotifier component), and then once the action has
completed (from the domain object's viewpoint), then the framework starts an objectstore xactn, executes the collated commands, and commits.

What the FlushTransaction does - at least did in NOF/Java - was to cause the objectstore xactn to be started early, ie during the action, in order that remaining statements within the action could see the changes in the DB. This is useful if there's a
repository call, for example.

That's the thing. A second call throws an error saying there is no transaction to end.
So does the first if I don't explicitly start one.

But now I am confused, as the transaction has not yet been committed to the DB right before the end of the controller method.
So if it automatically starts a transaction, why is it not there for me to explicitly end. That was my whole problem to start with.

this is one area where things are quite different now with Entity Framework.

We actually use the EF proxies which are doing the change tracking etc for us. When the transaction commits at the end we just 'saveChanges' on the EF context.

Jacques,

So something to check is what you're making the changes on - I suggest you check the objects to make sure they're EF proxies (if persistent) or NOF proxies (while transient - the NOF proxy is swapped for a EF proxy when the object is persisted). It's
fairly clear if you look at the runtime type of an object in the debugger - it will be a generated subtype of your domain type.

this is one area where things are quite different now with Entity Framework.

We actually use the EF proxies which are doing the change tracking etc for us. When the transaction commits at the end we just 'saveChanges' on the EF context.

Jacques,

So something to check is what you're making the changes on - I suggest you check the objects to make sure they're EF proxies (if persistent) or NOF proxies (while transient - the NOF proxy is swapped for a EF proxy when the object is persisted). It's fairly
clear if you look at the runtime type of an object in the debugger - it will be a generated subtype of your domain type.

>So something to check is what you're making the changes on - I suggest you check the objects to make sure they're EF proxies (if persistent) or NOF proxies (while transient - the NOF proxy is swapped for a EF proxy when the object is >persisted).
It's fairly clear if you look at the runtime type of an object in the debugger - it will be a generated subtype of your domain type.

They are all persistent proxies.

I fail to see how this will help me ensure that the transaction is committed at a specific point.

>So something to check is what you're making the changes on - I suggest you check the objects to make sure they're EF proxies (if persistent) or NOF proxies (while transient - the NOF proxy is swapped for a EF proxy when the object is >persisted).
It's fairly clear if you look at the runtime type of an object in the debugger - it will be a generated subtype of your domain type.

They are all persistent proxies.

I fail to see how this will help me ensure that the transaction is committed at a specific point.

>So something to check is what you're making the changes on - I suggest you check the objects to make sure they're EF proxies (if persistent) or NOF proxies (while transient - the NOF proxy is swapped for a EF proxy when the object is >persisted).
It's fairly clear if you look at the runtime type of an object in the debugger - it will be a generated subtype of your domain type.

They are all persistent proxies.

I fail to see how this will help me ensure that the transaction is committed at a specific point.

If the objects being changed are not proxied any changes will not be submitted to the database as EF simply isn't aware of them. That would be the same symptoms as the problem you're seeing.

Try turning the logging right up to DEBUG and log a single action to a file. It logs on each 'SaveChanges' and I think records the number of changes saved.

If the objects being changed are not proxied any changes will not be submitted to the database as EF simply isn't aware of them. That would be the same symptoms as the problem you're seeing.

But then they wouldn't be save to the database at all when the controller action is done.

But they are saved to the database. Just notat the point where I want them to be.

public ActionResult MyControllerAction ( params )
{
try
{
// If I don't have this start, the end transaction throws an error.
NakedObjectsContext.ObjectPersistor.StartTransaction ();

// Call into the model, making changes.

NakedObjectsContext.ObjectPersistor.EndTransaction ();

// Here I do the call to the external service that expects the data, but the data is not always there.

return jsonNetResult;
}
catch (Exception ex)
{
// This correctly rolls back the transaction if there was an error.
NakedObjectsContext.ObjectPersistor.AbortTransaction ();
throw;
}
}
// At this point, after the controller action returns, the data is always in the DB.

You have said you're inheriting from NakedObjectsController. That starts a transaction in 'OnActionExecuting' and ends it in 'OnActionExecuted' both which should be called by the MVC framework.

I suggest you restructure your code and override OnActionExecuted in your controller. Call the base method which should end the transaction and then add your code that calls to the external service. Take a look at the override of OnActionExecuted in
GenericControllerImpl.