PerThreadUnitOfWorkScope<UnitOfWork>

Hi Ivan :),
in our WCF scenario we are using PerThreadUnitOfWorkScope<unitofwork> shared in service accross thread. But we have following problem - if we try to update invalid object it throws ValidateException but remains in shared unit of work and throw this exception again and again if we try save another object. No problem if I try Add - I can validate with IsValid before, but while Update i'm changing object and there is no way back - what are you suggesting? Thread safe disposing if error occured?
Sample of using UOW in Serivce

[ServiceBehavior(InstanceContextMode = InstanceContextMode.Single)]
    
    public partial class Service
    {
        LightSpeedContext<unitofwork> context;
        PerThreadUnitOfWorkScope<unitofwork> lsScope;
        private static readonly ILog Logger = LogManager.GetLogger(
           System.Reflection.MethodBase.GetCurrentMethod().DeclaringType);
        public Service(string ConnectionString)
        {
            LightSpeedContext.Default.Logger = new ConsoleLogger();
            this.context = new LightSpeedContext<unitofwork>();
            this.context.DataProvider = DataProvider.SqlServer2005;
            this.context.ConnectionString = ConnectionString;
            lsScope = new PerThreadUnitOfWorkScope<unitofwork>(context);
            //because localization
            Thread.CurrentThread.CurrentCulture
                = Thread.CurrentThread.CurrentUICulture
                  = CultureInfo.CreateSpecificCulture("cs-CZ");
        }
    }

I would suggest calling BeginEdit before starting to apply changes to the entity.  Once you have applied all the changes, you can validate the object.  If all is well, you can then call EndEdit to confirm the changes.  If not, you can call CancelEdit to revert the entity back to the state it was in before you called BeginEdit.

While updating more objects in transaction (TransactionScope) should I call this on everyone object?

You should call BeginEdit on every object that you may want to revert.  So if you are modifying and saving a set of objects within a TransactionScope, but you are worried that the modifications may make the objects invalid, you would call BeginEdit on each object.

You will want to consider when to call EndEdit/CancelEdit.  Specifically, if you want to revert ALL the entities if any one entity is invalid (transactional behaviour for the in-memory entities), then you will need to defer calling EndEdit/CancelEdit until you have modified all entities and tested that they are valid.

Hi, if I try to CancelEdit I got error at Lib\Mindscape.LightSpeed\Src\Framework\Entity.cs:line 339 Cannot retype to System.ComponentModel.IEditableObject (it's not direct child of Entity)

Could you post a small sample project (e.g. a console application) that reproduces this please?  I'm not aware of any need for objects to be directly derived from Entity (if that's what you mean by "direct child" -- or did you mean in the sense of parent-child relationship?).  You can attach a zip file via the Options tab, or email it to ivan @ the obvious domain name if it contains sensitive information (please make sure you remove any EXEs or DLLs from the zip file).  We will then look into it for you.  Thanks!

I sent it (by email). (SQL Script with the schema and unit test is attached)

Thanks.  This appears to be a bug in the handling of one-to-one associations.  I have committed a fix and it will be included in nightly builds dated 22 Jan 2009 and above, available from the store after about 1430 GMT.

great! thank you very much, i'll try it

Hi, it's possibility to attach all edited obejcets to TransactionScope? If I would call BeginEdit on Entity and at the same time in one transaction I would call BeginEdit on another Entity I will call EndEdit or CancelEdit automatically on all edited objects at the end if scope.Complete() called. It's more complicated in case if I would call functions in tranasction scope, these have own transaction scopes(and can be called separatelly) I will do this automatically - so one idea is LightSpeed do it automatically (connected to transaction scope if present) or I can programm something as "EditationManager" where I will register every edited Entity in my transaction and pass this manager to every called function to register other edited objects. On parent level I will call End or CancelEdit on all entities in this manager. (it's more complicated but I tried to simplify it) What do you mean?

Making LightSpeed objects inherently transactional would be a significant change to their behaviour -- most CLR objects are not transactional, so it would be potentially surprising as well as a possibly breaking change for existing code.

Therefore some sort of EditManager is probably more viable.  Don't forget if you are targeting .NET 3.5 you can create extension methods on the Entity class -- for example you could create a BeginTransactionalEdit() extension method which called BeginEdit and, if there was a transaction in progress, registered the object with the EditManager, or attached to the Transaction.Current.TransactionCompleted event (though I am not sure how you would handle rollback in this scenario).

You will want to be a bit careful here because transactions can nest but BeginEdits can't -- if you do a BeginEdit, then make some changes, then do another BeginEdit, the entity is now checkpointed at the *second* BeginEdit.  You can't go back to the state before that.  So your extension method may want to check whether the entity is already registered with EditManager (i.e. there is already an edit in progress) and not call BeginEdit if that is the case.