We've got a problem with the batched execution as follows:

  • In a Person object an Address should be present. When no Address is present in the List, a new one is created.
  • In the Address we have an AddressType (Home Address, Bussiness Address, etc). The reference for this one is set to 'not nullable'
  • In the Constructor of Address the Default for the AddressType is fetched from the AddressType Table.
  • During the fetch of the Default AddressType a batch SQL Query is started, which is trying to save the Address. The DB does not allow this because the AddressType is NULL.

Can we suspend batches during initialization? We've already tried the Validation.Disable() (see below) but that didn't prevent the batch from executing.

Regards Paul Sinnema Diartis AG

using (var inconsistentArea = Validation.Disable())
                        Z_Supplement1 = string.Empty; // Setting string default
                        Z_Supplement2 = string.Empty; // Setting string default
                        Z_Street = string.Empty; // Setting string default
                        Z_BuildingNumber = string.Empty; // Setting string default
                        Z_PostOfficeBox = string.Empty; // Setting string default
                        Z_PostOfficeBoxNumber = string.Empty; // Setting string default
                        Z_Comment = string.Empty; // Setting string default
                        Z_AddressType = AddressType.Default; // Setting single navigation default

                        if (createArgumentsIn != null)
                            AddressCreateArguments createArguments = (AddressCreateArguments)createArgumentsIn;

                        EntityStateP.Value = EntityState.CreatedNew;

Updated at 14.07.2010 16:25:17


While trying to create a work-around for this issue (viewtopic.php?f=29&t=6014) this situation was produced.

What I tried to do is create the object in a different session, persist it to the DB and refetch it in the main session. What I forgot was to add a DisconnectedState to the temporary session. This caused the batches to fire.

B.t.w. This work-around gives other problems. We now get an exception which is the same as an issue described here: viewtopic.php?f=29&t=5828&start=0&hilit=differs

Regards Paul Sinnema

Updated at 14.07.2010 18:09:35

Can we use this in the Constructor?

using (session.Pin(this)) { 
  // this Entity isn't persisted here

Updated at 18.07.2010 14:44:07

Ignoring would mean the code is in there but it does nothing. So programmers will never get a message that they programmed something wrong.

I'm always at the standpoint that when something isn't allowed it should throw an exception with a clear message, so programmers know what they did wrong.

This thread was imported from our support forum. The original discussion may contain more detailed answer.

asked Jul 14 '10 at 14:16

Paul%20Sinnema's gravatar image

Paul Sinnema

Does pinning help here? I mean:

using (session.Pin(someEntity)) { 
  // someEntity isn't persisted here
(Jul 14 '10 at 14:16) Alex Yakunin Alex%20Yakunin's gravatar image


(Jul 14 '10 at 14:16) Alex Yakunin Alex%20Yakunin's gravatar image

One Answer:

AndresRohr wrote:

Thanks Alex. We implemented this in all our constructors but now we have a problem when a constructor calls another constructor to fill it's navigation property. Please see the attached screenshot of the debugger including the call stack. I think that each constructor opens a new transaction scope. Then if the nested transaction scope (DossierPayment) is disposed it looks whether there are pinned entities. But it looks for pinned entities not only on it's own scope but global. So, on the nested scope there are no pinned entities, but on the parent scope (DossierFinancialHelp) there are some. I think the solution is that on a TransactionScope.Dispose it must only check whether there are pinned entities on it's scope and subscopes but not on parent scopes.

Alex (Xtensive) wrote:

I'm unable to look up this closer yet, but I have a hint: when entity is pinned, all the entities referencing it considered as pinned as well - i.e. changes made to them won't be persisted as well until the originally pinned entity is unpinned.

May be this will help.

answered Jul 15 '10 at 11:23

Editor's gravatar image


Hi Alex,

I guess we only need 'pinned' entities when we don't use the DisconnectedState. We now have mix of this. After removing the 'pin' method from our constructors this problem goes away.

Regards Paul

(Jul 15 '10 at 11:23) Paul Sinnema Paul%20Sinnema's gravatar image

Yes, exactly - it seems we must either deny or ignore Session.Pin calls while Session.IsDisconnected==true.

What's the best option?

(Jul 15 '10 at 11:23) Alex Yakunin Alex%20Yakunin's gravatar image

But persist can't happen while DisconnectedState is attached, so ignoring pinning seems safe here. At least, I don't imagine any negative effects of this. Does this change anything?

(Jul 15 '10 at 11:23) Alex Yakunin Alex%20Yakunin's gravatar image

No, is ok

(Jul 15 '10 at 11:23) Paul Sinnema Paul%20Sinnema's gravatar image


(Jul 15 '10 at 11:23) Alex Yakunin Alex%20Yakunin's gravatar image
Your answer
Please start posting your answer anonymously - your answer will be saved within the current session and published after you log in or create a new account. Please try to give a substantial answer, for discussions, please use comments and please do remember to vote (after you log in)!
toggle preview


Once you sign in you will be able to subscribe for any updates here



Asked: Jul 14 '10 at 14:16

Seen: 3,576 times

Last updated: Jul 14 '10 at 14:16

powered by OSQA