Archived

This forum has been archived. Please start a new discussion on GitHub.

Identity Map for Freeze Evictor

Hi,

I assume that freeze has a way to find an object from its identity (hasObject() does this, but doesn't return the object, just a bool). I also assume that this is the primary key for Berkeley.

Can I "find" on this index, to return an object based on its identity? I'd hate to create a second index if you already have one created just for this purpose. Perhaps I have just missed something in the documentation -- wouldn't be the first time.

Thanks In Advance,

-- Andrew Bell
andrew.bell.ia@gmail.com

Comments

  • bernard
    bernard Jupiter, FL
    Hi Andrew,

    The Freeze Evictor has no find() or lookup() operation because the returned object could be evicted from the evictor cache at any time.

    You can use locate()/finished() on the Evictor (a ServantLocator) to load/grab and later release an object given its identity; to do so, you just need to manufacture a proper Current.

    Of course, if you just need to access an object through its Slice-interface, manufacturing a proxy and calling on this proxy is much simpler.

    Best regards,
    Bernard
  • locate() and the ASM

    Thanks for the info. I wasn't thinking through the whole chain of events.
    You can use locate()/finished() on the Evictor (a ServantLocator) to load/grab and later release an object given its identity; to do so, you just need to manufacture a proper Current.
    The documentation says that a check is made in the ASM for the object and only calls locate() if the object isn't in the ASM. Is it an error to call locate() for an object that already has a servant? It looked to me like the code the EvictorI::locate() calls Cache::pin(), which will check the Cache::_map and return the servant from there if it exists, but I wanted to check just to be sure.
    Of course, if you just need to access an object through its Slice-interface, manufacturing a proxy and calling on this proxy is much simpler.
    On the idea of just calling createProxy() on the identity and then making a call, is the marshall/unmarshall stuff small enough overhead that I should ignore it and, as you say, do it the easy way? It just seems unfortunate to have to go through that on the server when I've already got everything needed to perform the operation other than the assurance that the object is resident.

    Thanks as always,

    -- Andrew Bell
    andrew.bell.ia@gmail.com
  • acbell wrote:
    On the idea of just calling createProxy() on the identity and then making a call, is the marshall/unmarshall stuff small enough overhead that I should ignore it and, as you say, do it the easy way? It just seems unfortunate to have to go through that on the server when I've already got everything needed to perform the operation other than the assurance that the object is resident.

    If you do not explicitly disable collocation optimization, there will be no marshaling or unmarshaling. Please see the Ice manual, Chapter "29.17 Location Transparency", for further details.
  • bernard
    bernard Jupiter, FL
    Hi Andrew,
    acbell wrote:
    The documentation says that a check is made in the ASM for the object and only calls locate() if the object isn't in the ASM.
    Correct.
    Is it an error to call locate() for an object that already has a servant? It looked to me like the code the EvictorI::locate() calls Cache::pin(), which will check the Cache::_map and return the servant from there if it exists, but I wanted to check just to be sure.
    The ASM and Cache::_map are unrelated maps. Remember that Ice does not insert the located servant in the ASM. And the implementation of the Freeze Evictor does not use the ASM at all -- you can call locate() for any object.
    On the idea of just calling createProxy() on the identity and then making a call, is the marshall/unmarshall stuff small enough overhead that I should ignore it and, as you say, do it the easy way?
    If your caller and servant are collocated (share the same communicator), by default the call is optimized: there is no marshalling or unmarshalling.

    Cheers,
    Bernard