Can you tell us when the FastLoadData gets built? The FastLoadData is NULL in a large number of records and I am wondering where to start on figuring out why....

asked Sep 17 '10 at 12:37

dku's gravatar image


edited Sep 17 '10 at 14:28

Alex%20Yakunin's gravatar image

Alex Yakunin

2 Answers:

FastLoadData field gets updated each time you persisted changes. So normally it must be none or few records with the null in the FastLoadData column.

Nulls would appear in the case of error during FastLoadData deserialization. Recently we had discover one possible reason of such an errors: DataObjects assumed that Type.GetProperties method returns PropertyInfos in the order properties defined in a class, but it is wrong. We had figured out that order PropertyInfos are being returned depends on e.g. what version of .NET runtime (32-bit or 64-bit) is currently running.

A consequences are really bad: Lets imagine two domains running in different environments(different .NET runtimes) but working with a same DB. FastLoadData produced by the first domain will differ from data produced by the second one and vice versa. Each attempt to deserialize wrong data in this circumstances will lead to error and nullifying FastLoadData field (Or even worse it would lead to reading wrong data!).

PS The error described is already fixed in our latest nightly build.

answered Sep 17 '10 at 14:21

Alex%20Ustinov's gravatar image

Alex Ustinov

edited Sep 17 '10 at 14:36

Nice - we answer concurrently here ;)

(Sep 17 '10 at 14:26) Alex Yakunin Alex%20Yakunin's gravatar image

Btw, check out my answer - I suspect his issue isn't related to environment change, i.e. there is just a normal post-upgrade case.

(Sep 17 '10 at 14:28) Alex Yakunin Alex%20Yakunin's gravatar image

FastLoadData is set to NULL during upgrade for any entity which properties were touched by upgrade.

It gets automatically rebuilt further - during reads (materialization). The probability of FastLoadData update during read of each entity having FastLoadData==null is determined by Session.InconsistentDataUpdateProbability, its default value is 50 (50%).

So if such delayed update isn't desirable (that's actually pretty inconvenient in some cases, since it turns read-only transactions into read-write, and in general, increases deadlock \ version conflict probability), you should do the following after regular upgrade:

  • Create a Session with Session.InconsistentDataUpdateProbability = 100
  • Loop through all the operations below until the query there will return no objects:
  • Start a transaction
  • Run a query like "Select top 1000 DataObject instances where {FastLoadData} is NULL" (unfortunately, I don't remember exact v3.9 query syntax, so there can be a mistake)
  • Enumerate all the entities there
  • Commit a transaction.
  • Probably, sleep for some period to decrease the concurrency, if this process runs in parallel with regular operations.

Hopefully, this will help.

answered Sep 17 '10 at 14:24

Alex%20Yakunin's gravatar image

Alex Yakunin

edited Sep 17 '10 at 14:30

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

powered by OSQA