Batch commit of a complex objects graph chnaged many times by the user

[Vitaliy]

Hi, Open Access team.

We are pleasant that you're still full of enthusiasm in the utility development.

I have used it to develop a new invoice payment module in our company system.
This time I trusted to it absolutely. The users edit a view object attribute. The view object sends a message to an Invoice persistent object. The invoice object code creates new Inoice payment (connected to several credit notes maybe). Then, the code groups invoice payments into a single remittance of a specific type and attached it to a batch.

The module passed all the tests. But we still have some problems. The most important one is when we almost sent several double payments to the bank.
Nobody can reproduce this bug.
A widely-spread commit errors are 'It is not allowed to read or write an instance marked for a deletion' or an error about duplicated OIDs. Ok, probably I tried to access to a deleted instance.

The only difference with the previous modules is that the view object updates the persistent objects immediately when the user changes the [Paid] attribute.

I can imagine that I could do mistakes in my programming, because it is difficult to manage a complex objects graph. But I can imagine that it is much more difficult to manage delayed changes of that complex objects graph. And maybe there are possible even theoretical problems there.
The user can place some amount into the [Paid] attribute (Invoice -> Invoice Payment -> Remittance -> Batch). Then clear it. Then place another amount. Or can do many other things that we don't know.

What the method would you suggest?
I mean every abstraction does 90% automatically but needs for 10% of 'manual efforts'
Should I break down the process onto view logic transactions? When no persistent objects (maybe not all of them) will be changed untill the user accepted all the changes.
I'm douing it actually. But Is this correct using of an ORM utility?
Or open access will do everything by itself?
And I just should worry about my own bugs? :-)

[Petko_I]

Hello Vitaliy,

We can discuss the issues you mentioned in the context of the visual designer, although the principles apply to the classic scope approach as well. An ORM tool such as OpenAccess is designed to manage complex object graphs. It just needs a bit of help from the side of the developer so that the context (OpenAccessContext in the case of the visual designer) cleanly performs its tasks. In this line of thoughts, a very important thing is the disposal of the context. The wrong disposal of the context opens opportunities for hard-to-find failures, especially with the connections or memory leaks. Allowing multiple changes to take place before committing them to the database means that a context is active for an extended period of time. It is a valid case since you do not want to persist data that will be changed numerous times until the user has made up his mind. The thing of importance here is to dispose of the context as early as possible. There are some help articles that may give you a hint as to how to manage the context lifecycle on a per-request basis in ASP.Net. You have specified that you develop a web site and I can only guess about the actual technology that you use (ASP, Silverlight). With regard to ASP we have a richer set of examples that you may find useful and accommodate them according to your needs. Here are some links in case you haven't looked at them yet:
Best Practices in web development with OpenAccess
Best Practices in web development with OpenAccess - Part Two

You can avoid the reading of deleted entities by checking the changes like this

query = context.Categories.ToList().Where(x => !context.GetChanges().GetDeletes<Category>().Contains(x))

Your usage of OpenAccess is correct as long as it does the job for you. Persisting changes in a batch is something that we support because it is a valid scenario required by cases such as yours. What worries us is the hard to track undesirable behaviors that you receive and which we would be most interested to resolve. Again, keeping the life of the context as short as possible (as it is designed to be light-weight and manage connections in a pool) will make sure that you make the job for OpenAccess easier.

Do not hesitate to contact us to further discuss this or other issues.

Greetings,
Petko_I
the Telerik team

[Vitaliy]

SQL 2005, C# 3.5, win forms, DevExpress grid control.
Any addition?

Actually, Petko_I  you answered on my question.
Thank you!

[Petko_I]

Hello Vitaliy,

We are glad you found an answer to your questions. Actually, we have a knowledge-base article which discusses the context lifecycle management. Here is a link in case you haven't had the chance to inspect it yet.

Feel free to ask us anything that comes to your mind.

Regards,
Petko_I
the Telerik team