Entity tracking and caching

I am using Nettiers v2.2. I would like to make use of the Microsoft Enterprise Library caching mechanism. From my understanding and research, Nettiers implements a custom cache manager under Entities.Entitymanager. I have set the EnableEntityTracking = "On"  and after some debugging,

I have relealized the following - that even if the cache is enabled the datalayer still queries the database via the ExecuteReader function.

Functions withing the Fill method then check whether the objects is cacheable or not and reads from cache to populate the rows into a TLIST<>.

I believe this goes against the use of the cache as the underlying database is still being queried. My goal is to improve performance  by caching

the rows from one of the base /static tables.   

 Any insights would be appreciated.

 Thanks

 public override DataLib.Entities.TList<Country> GetAll(TransactionManager transactionManager, int start, int pageLength, out int count)
        {
            SqlDatabase database = new SqlDatabase(this._connectionString);
            DbCommand commandWrapper = StoredProcedureProvider.GetCommandWrapper(database, "dbo.usp_tb_country_Get_List", _useStoredProcedure);
            
            IDataReader reader = null;
        
            //Create Collection
            DataLib.Entities.TList<Country> rows = new DataLib.Entities.TList<Country>();
            
            try
            {
                //Provider Data Requesting Command Event
                OnDataRequesting(new CommandEventArgs(commandWrapper, "GetAll", rows));
                    
                if (transactionManager != null)
                {
                    reader = Utility.ExecuteReader(transactionManager, commandWrapper);
                }
                else
                {
                    reader = Utility.ExecuteReader(database, commandWrapper);
                }        
        
                Fill(reader, rows, start, pageLength);
                count = -1;
                if(reader.NextResult())
                {
                    if(reader.Read())
                    {
                        count = reader.GetInt32(0);
                    }
                }
                
                //Provider Data Requested Command Event
                OnDataRequested(new CommandEventArgs(commandWrapper, "GetAll", rows));
            }
            finally
            {
                if (reader != null)
                    reader.Close();
                    
                commandWrapper = null;    
            }
            return rows;
        }//end getall
        
        #endregion

 I had to change the scripts on my project to add a caching mechanism similar to yours. );

The other option is to override methods on the DataProviders to cache queries... since I want a more flexible mechanism, i decided to change the scripts... );

Mark,

you have a few options here, and it all depends on which interfaces (DataProviders, Services, or Component) do you use to get to your entities.

If you use the Services, you can easily override the appropriate get method in the <Entity>Service class.  In this override you can check in the cache through the EntityManager as the first step, if you get a hit from the cache, return.  If not, delegate the call to your base class.

Wow, I never really noticed that with EntityTracking but your absolutely right.  The chicken before the egg thing, since they track the cache at the Entity level and not the Query level, it has to do the query to know which entities to find in the cache.  Lol, that's not much of a savings.

Well, I don't like the Entity Tracking at all.  It has gotten us into so much trouble here it's pathetic.  You can't selectively turn it on or off, it's always on or off.  And then with your finding, it definetely isn't doing us any good.  I am not sure if it is the job of the generated code to cache or not, that is probably debatable, but maybe some hooks to allow you to cache the way you want would be good.  Not sure the design decision on this as to why they did it this way either.  Being open source it is sometimes hard to track down who suggested it, why it is the way it is stuff.

We cache everything at multiple levels, some client side, some server side...we use a Win Client & ASP.NET that hits a remoting server.  We can cache stuff either at the client / asp side or at the remoting side.  That's where I see it tough for Generated code to cache the way everyone wants to cache.  Providing some extensibility here would be best and then you can either use the default scheme or write your own.

jeff

Hi Guys,

Sorry for the late reply but dead busy. I do appreciate all your feedback re the cache issue.

I have decided to give it a pass to the inbuild cache mechanism. To be honest, I don't like changing much of the .generated. nettiers code. So disabled the cache mechanism completely. Still can't understand ho, such a great product could miss this out...or can't understand the intended logic behind it...Well thoguh I have to say that nettiers is a great product overall...

MeanwhileI have had a look at Microsoft Enterprise Cache library and I will implement the required cache objects manually using the library at the Parent Tier. This give me absolute control and cache only the required objects.

Thanks alot again for your input...

Mark