How to avoid caching in some particular contexts?

Thread is closed for posting
4 posts, 0 answers
  1. tmlipinski
    tmlipinski avatar
    131 posts
    Member since:
    Dec 2006

    Posted 26 Apr 2009 Link to this post

    Hi,

    Below, a  web application is considered.

    There is a persistent class User residing in the OrgStruct.dll library. I need to have an access to users (the User class) from another, low level library, the Lib.dll, but I can't just reference OrgStruct.dll because OrgStruct.dll already references Lib.dll: it's a well known circular references problem. And I don't want to get a copy of some User's data - I need a fully functional User object. Therefore the User class is seen in Lib.dll as an interface IUserBasic (one of its method is GetUser(int id)) and a static object of this interface (this object serves as a IUserBasic objects creator). The application while starting creates a dummy User object and sets this static object in Lib.dll to this one. And it works well - Lib.dll can read any user object without knowing anything about OrgStruct.dll.
    But now, I want to assure Lib.dll that the data it is reading are not cached, that they are as up to date as possible. What can I do:

    1. Read the User object inside an open transaction:
    1a. Use the static scope from the context provider. But it is a web application and this scope is shared by all sessions. I'm not sure if beginning transactions it this object is a good solution.
    1b. Use a new scope object. But in this case this scope should be created, used and disposed by the GetUser method. The scope cannot be created by Lib.dll because Lib.dll knows nothing about OrgStruct.dll (and even knows nothing about Telerik.OpenAccess). But in this case I cannot use the object created by GetUser outside this method because I get a message that the object's scope is already closed (or disposed or something like that).

    2. Use IObjectScope.Evict method. This works well (functionally) but it requires the object to evict. And getting this object has some disadvantages:
    - looking for this object using its PK and IObjectScope.GetObjectById: when the object is not in the cache it is searched in the database (see: this thread)
    - looking for this object using search criteria other than PK: again, when the object is not in the cache it is retrieved from the database just to be removed from the cache and to be retrieved from the database again

    The second solution works better but has unneccessary database reads.

    So, what is your advise?

    Regards
    Tomasz
  2. Jan Blessenohl
    Admin
    Jan Blessenohl avatar
    707 posts

    Posted 27 Apr 2009 Link to this post

    Hello tmlipinski,
    You are right that the web page should not access the objectscope directly. What I am doing in those cases, The page instantiates a business object which instantiates a data access layer object which instantiates an objectscope. This business object can now be created in the postback and disposed in the overwritten page.Dispose method. This pattern allows you to have a seperate scope per postback which helps a lot in accessing clean data.

    Best wishes,
    Jan Blessenohl
    the Telerik team

    Instantly find answers to your questions on the new Telerik Support Portal.
    Check out the tips for optimizing your support resource searches.
  3. tmlipinski
    tmlipinski avatar
    131 posts
    Member since:
    Dec 2006

    Posted 27 Apr 2009 Link to this post

    Hi,
    OK, this solves my problem. I can add the reference to Telerik.ObjectAccess (to have IObjectScope interface available) or even not to add it - and keep it at the page level as an anonymous object.

    Thanks
    Tomasz
  4. Dimitar Kapitanov
    Admin
    Dimitar Kapitanov avatar
    632 posts

    Posted 28 Apr 2009 Link to this post

    Hello tmlipinski,


    Sincerely yours,
    Author nickname
    the Telerik team

    Instantly find answers to your questions on the new Telerik Support Portal.
    Check out the tips for optimizing your support resource searches.
Back to Top