ExecuteQueryAsync never returns

 

I've written the code below in order to speed up the preloading of certain entities into the cache. The ExecuteQueryAsync however never call the callback routine and no exceptions are thrown. What is wrong with this code?

 

Regards,

Paul Sinnema

Diartis AG

 

  /// <summary>
  /// Pre-load all the Navigation properties
  /// </summary>
  public void LoadAllNavigationProperties()
  {
   loader = new AsynchronousLoader();
   loader.Add<CivilStatusType>(ModelContext.Instance.KLIBDefaultManager, (IEntityQuery<CivilStatusType>)CivilStatusType.Where(Item => Item.IdKLIBAlias >= 0));
   loader.Add<Person>(ModelContext.Instance.KLIBDefaultManager, (IEntityQuery<Person>)Person.Where(Item => Item.IdKLIBAlias >= 0));
   loader.Add<SeparationType>(ModelContext.Instance.KLIBDefaultManager, (IEntityQuery<SeparationType>)SeparationType.Where(Item => Item.IdKLIBAlias >= 0));
   loader.Add<CivilStatus>(ModelContext.Instance.KLIBDefaultManager, (IEntityQuery<CivilStatus>)CivilStatus.Where(Item => Item.IdKLIBAlias >= 0));
   loader.Add<CorrespondenceLanguage>(ModelContext.Instance.KLIBDefaultManager, (IEntityQuery<CorrespondenceLanguage>)CorrespondenceLanguage.Where(Item => Item.IdKLIBAlias >= 0));
   loader.Add<Address>(ModelContext.Instance.KLIBDefaultManager, (IEntityQuery<Address>)Address.Where(Item => Item.IdKLIBAlias >= 0));
   loader.Add<Communication>(ModelContext.Instance.KLIBDefaultManager, (IEntityQuery<Communication>)Communication.Where(Item => Item.IdKLIBAlias >= 0));
   loader.Add<Contact>(ModelContext.Instance.KLIBDefaultManager, (IEntityQuery<Contact>)Contact.Where(Item => Item.IdKLIBAlias >= 0));
   loader.Add<Nationality>(ModelContext.Instance.KLIBDefaultManager, (IEntityQuery<Nationality>)Nationality.Where(Item => Item.IdKLIBAlias >= 0));
   loader.Add<PostalCode>(ModelContext.Instance.KLIBDefaultManager, (IEntityQuery<PostalCode>)PostalCode.Where(Item => Item.IdKLIBAlias >= 0));
   loader.Add<Country>(ModelContext.Instance.KLIBDefaultManager, (IEntityQuery<Country>)Country.Where(Item => Item.IdKLIBAlias >= 0));
   loader.Add<Gender>(ModelContext.Instance.KLIBDefaultManager, (IEntityQuery<Gender>)Gender.Where(Item => Item.IdKLIBAlias >= 0));
   loader.Add<LastName>(ModelContext.Instance.KLIBDefaultManager, (IEntityQuery<LastName>)LastName.Where(Item => Item.IdKLIBAlias >= 0));
   loader.Add<AddressType>(ModelContext.Instance.KLIBDefaultManager, (IEntityQuery<AddressType>)AddressType.Where(Item => Item.IdKLIBAlias >= 0));
   loader.Add<CommunicationType>(ModelContext.Instance.KLIBDefaultManager, (IEntityQuery<CommunicationType>)CommunicationType.Where(Item => Item.IdKLIBAlias >= 0));
   loader.Add<ContactRelationRoleType>(ModelContext.Instance.KLIBDefaultManager, (IEntityQuery<ContactRelationRoleType>)ContactRelationRoleType.Where(Item => Item.IdKLIBAlias >= 0));
   loader.Add<Relation>(ModelContext.Instance.KLIBDefaultManager, (IEntityQuery<Relation>)Relation.Where(Item => Item.IdKLIBAlias >= 0));
   loader.Add<RelationType>(ModelContext.Instance.KLIBDefaultManager, (IEntityQuery<RelationType>)RelationType.Where(Item => Item.IdKLIBAlias >= 0));
   loader.Add<Organization>(ModelContext.Instance.KLIBDefaultManager, (IEntityQuery<Organization>)Organization.Where(Item => Item.IdKLIBAlias >= 0));
              loader.Execute();
  }

 

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using IdeaBlade.EntityModel;
using System.Collections;

namespace Diartis.KLIB.KLIBLibrary
{
    /// <summary>
    /// This class take care of filling the DevForce cache asynchronously.
    /// </summary>
    public class AsynchronousLoader
    {
        private List<object> m_Items = new List<object>();

        public AsynchronousLoader()
        {
        }

        /// <summary>
        /// Add a query to the collection
        /// </summary>
        /// <param name="manager"></param>
        /// <param name="query"></param>
        public void Add<TType>(EntityManager manager, IEntityQuery<TType> query)
            where TType : Entity
        {
            AsynchronousLoaderItem<TType> item = new AsynchronousLoaderItem<TType>(manager, query);

            m_Items.Add(item);
        }

        /// <summary>
        /// Execute all added queries
        /// </summary>
        public void Execute()
        {
            foreach (var item in m_Items)
            {
                AsynchronousLoaderItemInterface itemInterface = (AsynchronousLoaderItemInterface)item;
                itemInterface.Execute();
            }

            bool allFinished = false;

            // Wait for all queries to finish
            while (!allFinished)
            {
                allFinished = true;

                foreach (var item in m_Items)
                {
                    AsynchronousLoaderItemInterface itemInterface = (AsynchronousLoaderItemInterface)item;
                    if (!itemInterface.IsFetched)
                    {
                        allFinished = false;
                        System.Threading.Thread.Sleep(10);
                    }
                }
            }
        }

        private interface AsynchronousLoaderItemInterface
        {
            void Execute();
            bool IsFetched { get; set; }
        }

        private class AsynchronousLoaderItem<TEntity> : AsynchronousLoaderItemInterface
            where TEntity : Entity
        {
            public AsynchronousLoaderItem(EntityManager manager, IEntityQuery<TEntity> query)
            {
                Manager = manager;
                Query = query;
                IsFetched = false;
            }

            private EntityManager Manager { get; set; }
            private IEntityQuery<TEntity> Query { get; set; }
            public bool IsFetched { get; set; }
            public IEnumerable Result { get; private set; }

            public void Execute()
            {
        object userStatus = new object();

        Manager.ExecuteQueryAsync(Query, EntityAsyncCompletedCallback, userStatus);
            }

            private void EntityAsyncCompletedCallback(EntityFetchedEventArgs args)
            {
                IsFetched = true;

                Result = args.Result;
            }
        }
    }
}

 

Pfew... quite the read. Thanks for the explanation. Its saturday now, I'll probably be trying this on monday. I'll discuss the solution with my colleagues and see if we can implement it in our application the way you suggested (with the progressbar and all).

 

Regards,

Paul Sinnema

Diartis AG

 

I've found what seems to be the cause. Haven't found a solution yet. We have implemented the Entities like this:

 

 

We use Inheritance in our project quite extensively and we didn't feel like typing the TypeOf() syntax all the time. The extensions need an IEntityQuery type and the properties produce an IQueryable<T> type. That why the compiler chokes.

 

Regard,

Paul Sinnema

Diartis AG

 

I don't follow why you are issuing multiple queries for subclasses of AbstractEntity. Not sure what "AbstractEntity" is. But if, as I suspect, it is the base class of a TPH inheritance hierarchy AND you are bringing down all the flavors of AbstractEntity in your pre-cache logic anyway ... why don't you grab all of the AbstractEntity instances in a single trip? That is, why ask for each subtype individually when you could get all of them in one shot with a query for AbstractEntity? Just a thought.

This statement worries me:

 

"It also produced problems which seem to be related to the order in which the data is retrieved from the DB"

 

Can you elaborate?

---

 

The type names in your example suggest that the entities you want to preload are pretty stable. Curious that you haven't looked into client-side offline caching. The load price is paid ONCE. Subsequently, the data are waiting on the client.

 

Not that hard to detect if one or more of these entity types have changed and need to be refreshed.

 

It's all work but not rocket science.

 

This is edge-caching in the extreme ... because the client is the edge.

 

---

 

There is ONE more thing to try: a reference entity batch retrieval service. Remote clients call it via EntityManager.InvokeServerMethod.

 

The server-side batch service builds up an EntityManager cache on the server. This it can do quickly because it is close to the database; minimal latency for the round trips. When done, it returns to the client a cache of heterogeneous entities in a single EntityCacheState object. Finally, the client imports this EntityCacheState into the client-side EntityManager.

 

This works best when you have a lot of little entity types to ship across the wire ... as one does when there are a ton of reference types like OrderStatus, Color, UsStates, UnitOfMeasure, Currency, etc.

 

You risk bogging down the middle tier if you make this too heavy. Of course you can farm it out to server-side "clients"; these are DevForce micro-applications, running on other machines near the server with 2-tier access to the database. The BOS service delegates the work to these "services" which build batches on their own time.  You pay a double remoting cost (helper service to BOS to remote client) in both directions but the server-side exchange is brisk.

 

---

 

Then you get clever. You realize that these data don't change much. So you cache them in these services ... or maybe in the BOS. This is edge-caching on the server. It can relieve pressure on the database. It doesn't require storing data on the client.

 

You'll want the reference entity batch service to go with it.

 

 

Refetch isn't that mysterious. Are you saying you can't even do a datasource-only, overwrite-changes query by PK for the entity (which is what a refetch would do)?

 

Assume a simple approach (you can complicated later). Assume a single basket of reference entity types. If any entity changes, the basket is invalidated. Assume also that you do not expect the reference basket to change much and that you will not refresh the client-side copy during a user session. Perhaps between sessions but, once loaded, that's it. Add the color "fuscia", it won't be an available color option until the next time the user launches the application.

 

Add a ReferenceEntityVersion table and entity. There is one record defined as {WellKnownGuid, DateTime, int counter}.

 

In the server, implement IEntityServerSaving. Your implementation of the required OnSaving method calls GetEntityManager on the EntityServerSavingEventArgs to get the manager with the entities that will be saved.

 

If any of those entites is an instance of a reference entity (you can just test the EntityGroups if you like), you know the basket must be invalidated.

 

You retrieve the lone ReferenceEntityVersion , update the DateTime, and increment the counter. The ReferenceEntityVersion entity is now among the entities that will be saved when you exit the OnSaving method.

 

If you're worried about concurrency, don't touch the counter; use a database table update trigger to increment it on update.

 

YOU HAVE ENSURED THAT THE SERVER KNOWS WHEN THE REFERENCE BASKET HAS CHANGED.

 

Now, on the client-side, if there is no basket on the client cache, you've got to go get it (remember that batch reference entity service I was talking about). This is probably the first time the client has been run on this PC.

 

Note that when you cached the reference entities locally on your client, you included the ReferenceEntityVersion among the reference entities in the basket. See ModelExplorer or PrismExplorer for example of how to save EntityManagerCacheState to IsolatedStorage; if you're not in Silverlight, you can save it in any wellknown location.

 

When you launch the next time, you find the local basket and load it into the EntityManager. You fetch the ReferenceEntityVersion from the server (your one trip to the server). If the two version entities match, you're good. If they don't, empty the EntityManager, delete the file on the local client, refetch the basket from the server , and save the new basket to the local file system (asynchronously of course). Continue with launch.

 

This is the foundation for something more dynamic or more granular. If you want something more dynamic, I'd would make sure that deletes are forbidden.

 

 

Regarding your question: "can we simple retrieve data on the server, transport it to the client and add it to the local cach-manager?"  The answer is "absolutely".

 

You are asking about the ability to invoke a server method which issues its own series of queries while on the server, gathers them into a EntityCacheState, and ships this back to the cllient as a single result. The client-side caller loads this EntityCacheState into the target EntityManager. In this way you could perform a bunch of queries on the server (no wire latency) and ship the results back in a single round trip.

 

To learn how to do this (with example), please file another support request so one of the regular support team can dig out the sample code and sent it to you.

 

Regarding the Refetch snippet: I see nothing obviously wrong with the call to manager.Refetch. I call Refetch all of the time and I know it works. Maybe there is something odd in your environment or something I'm just not seeing. Maybe you can make a small test case: spin up your manager and just try refetching entities directly. I think you'll find it works fine.

 

May I say that your T4 approach troubles me. The code you are generating here is quite generalizable. Did you consider creating a BaseEntity class and inheriting from it? The refetch method would work just fine in such a base class.

 

Personally I would avoid generating entity code if I could and would generate the bare minimum if I felt forced into it. In a version of DevForce coming to you soon, you will be able to modify the code we generate with very simple overrides; there should be know need to have your own entity code gen then ... and you'll avoid the headaches that must abound as you try to get the code generation/update timing right.

 

Regarding the PushNotification snippet: A lot going on in there. I didn't understand many of the choices. For example, you do identity checking inside the Foreach loop. At a minimum you can (and should) pull the tests on Manager principal out as they cannot change during the loop. I don't know why you're serializing/deserializing the data; we do that for you automatically.

 

Please don't toggle the managers.DefaultQueryStrategy in the middle of your process. I see this from others too. Instead, give the query itself the strategy it should have.

 

This loop is going to make a separate round trip to the server for each added and modified entity. That's going to be painful if your notification has many changes. Supposing I got 20 orders and 100 order details via push, I'd fire off two queries - an Order query and an OrderDetails query - rather than make 120 queries! Yes, you can construct a query that retrieves by multiple Ids.

 

I don't understand why you care whether the added/modified entity is in your cache given that you've marked each EntityInfo with the client user's identity (aside: a user id would have been simpler ). If I told the server I'm interested in entity X, why would I not want to receive entity X? When it's an added entity you always add it to your cache anyway.

 

Some of what I have in mind exceeds what can reasonably be said in a forum post. You might want to purchase a few hours of professional services to get you over some of these hurdles.

Cheers, W

 

 

Here's another observation. I avoid having an entity perform a persistence operation on itself, such as this refetch method. If I have to do such a thing, I make sure that the entity uses its own EntityManager. Accordingly, had I written such a method, I'd have written something like:

 

    var ea = this.EntityAspect;

    // An important guard clause that was overlooked.

    if (null == ea || ea.IsDetached()) return; 

    ea.EntityManager.RefetchEntity(this, MergeStrategy.OverwriteChanges);

 

Of course this wouldn't help in this code sample where the entity's EM and the method's EM are probably different; it would merely repeat the effect Paul experiences ... in which the refetch seems not to happen (it actually does happen ... albeit in the default EntityManager).

 

 

 

As written there are innumerable places for surprises to hide (what happens, for example, if the entity does not implement IKLIBEntity? Answer: the entity is not fetched. Is that the answer that fulfills the intent? What happens if the IKLIBEntity-implementing entity is not in cache? Answer: Attempted refetch of a NullEntity (I think this bombs).

 

--

 

Btw, I realize that the query or refetch the way I "recommended" would not engage the additional machinery of the "Refetch" method buried in the entity, namely the lines:

 

   this.AddMessage(MessageType.Warning, User.Translator.Translate("AbstractEntity") + " " +
                   User.Translator.Translate("Refetched"), this, null);
   
   Refetched.Call(this, EventArgs.Empty);

Assuming this is desirable (and it does not seem so to me), I'd write an EntityManager extension method that I could call anywhere, e.g.:

 

   public static void KLIBRefetch(this EntityManager manager,

            EntityWrapper entity, MergeStrategy strategy) {

 

       manager.RefetchEntity(entity, strategy);

 

           User.Translator.Translate("AbstractEntity") + " " +
                   User.Translator.Translate("Refetched"), this, null);
   
        Refetched.Call(entity, EventArgs.Empty);

   }

 

Presumably there is a way to find the appropriate "Logger" and "Refetched"

 

 

I'm not trying to beat up on you Paul. But I can't have people reading the forum thinking that this is the IdeaBlade way. You may have your reasons and may yet get it to work. That's fine.