There are two options:

• DisconnectedState.CancelChanges() invocation makes it to forget all the cached state & operation log.

• Transaction.Open for Session with attached DisconnectedState opens a local transaction for DisconnectedState. So if it's cancelled, the changes made in it will be rolled back. DisconnectedState fully support nested transactions.

So you can consider:

• AcceptChanges\CancelChanges commits or rollbacks a top-level transaction for the whole DisconnectedState;

• Transaction.Open opens a nested one; nesting level is unlimited.

It's also important to know how DisconnectedState attachment affects on real database-level transactions:

• Obviously, real database transactions can be created only inside DisconnectedState.Connect() block and AcceptChanges() call.

• A single AcceptChanges() call is executed in a single real database transaction

• Currently a single Connect() call may lead to creation of a single transaction at max, which will be closed (committed, but this is actually not important, since only read-only operations can happen there) on either disconnection or detachment of DisconnectedState.

"Currently" here implies that shortly we'll add more options allowing to control this. E.g. in some cases it might be desirable to create a single transaction for each local top-level transaction inside Connect() blocks.

Now exact answers:

> How can i handle entity to discard changes when user selects Cancel button? What would be the best pattern to handle both scenarios "Add New/Cancel, Edit/Cancel"?

I'd use transactions (Transaction.Open).

Global Apply/Commit buttons may reply on AcceptChanges/CancelChanges.

> Is it possible to perform rollbacks on disconnected transactions?

Yes (described above).

> Or should I reset disconnected Session and perform reload of entire DB (which i dont want)?

No, you shouldn't. Err... I made a mistake about CancelChanges: it makes DS to forget only operation log an modifications you've made. All the data cached in DisconnectedState stays there.

> If that is the case is it possible to keep entities form previous session and reload only the one that was modified and canceled?

This is not a case. But if you need to keep some cached state or attach it to two or more Sessions, you can clone it using .NET serialization.

We have a nice helper class for this - Cloner (in Core). An example:

var disconnectedStateCopy = Cloner.Default.Clone(disconnectedState);

> Is it there any support for creating Copyes of Entities?

What exactly do you mean? Identity must work anyway, so you can't copy an entity to create its another version for e.g. different editor (i.e. to produce something like modifiable view of entity). But you can copy the whole DS, attach it to another Session and get the clone there.

Another possible reason is to really clone some Entity - e.g. to create a copy of Task from its template (Task as well). We don't provide any default implementation here, but DO supports serialization (actually, beta - i.e. this isn't thoroughly tested), so you can use nearly the following code to create a copy:

Task newTask;
using (var serializationScope = (new SerializationContext(SerializationKind.ByValue)).Activate()) {
  newTask = Cloner.Default.Clone(taskTemplate);
}

> Is there any other way to isolate Entity that is being modified?

No way to isolate a single one, but it's easy to isolate the whole graph.

> Is there any way to share same entity among several sessions (connected and disconected)

What does this exactly mean?

• It's impossible to share the same entity state. The state is always isolated.

• By any other mean it is shared.

Actually, there is a related question: how to properly deal with Sessions in e.g. MDI UI. I'll write a reply on this shortly.

Forgot to add: currently you must call Session.NotifyChanged() method manually after rollbacks \ CancelChanges, or simply rebind the UI displaying affected objects (~ var tmp = primaryControl.DataContext; primaryControl.DataContext = null; primaryControl.DataContext = tmp;).

This will be fixed shortly.

Issue: http://code.google.com/p/dataobjectsdot ... ail?id=616