1 2 Previous Next 25 Replies Latest reply: Jul 1, 2010 5:44 AM by Manik Surtani Go to original post RSS
  • 15. Re: CacheLoader w/ JPA or Hibernate backend
    Manik Surtani Master

    Second one - this I sincerely did not get what you meant... while designing I saw that we had two paths to take:

      1st: assume the ID for the cache is the same as for the entity and give users means for looking up the cache by the id.

      2nd: let the user specify either the regular key or a natural immutable key (gives greater flexibility but increases store complexity a lot)

    Yes, but a simple entity ID may not be enough.  Consider that I have 2 entities: Person and Address.  Person's ID is an autogenerated long.  Address's ID is an autogenerated long.  So what should cache.get(5L) return you?  A Person or an Address? 

    Third one - I was really uncomfortable with this expiry time in my store impl since at first I was thinking of providing means for the user to have a fast access layer to persistent entities through infinispan... something like seeing Hibernate the other way around. This way, we cant assume the user will have a timestamp field in its entity that we can use as a expiry time since we are talking about entities... do you think this violates way too much what loaders are for? Sincerely... I see a huge room for applications on top of this idea (there are a miriad of huge volume transactional applications today that needs a super fast storage area for looking up additional processing data).

    Absolutely.  Perhaps you could provide an additional annotation to annotate any arbitrary field or getter to retrieve expiry information from an entity.

    Fourth and last one: I thought about having each loader serving a single entity (or an entity hierarchy).

    You mean 1 cache per entity/entity-hierarchy.  Makes sense, and steps around the problem if IDs I described above.  But this should be optional - people may still want 1 cache for all entities.

  • 16. Re: CacheLoader w/ JPA or Hibernate backend
    Rafael Ribeiro Novice

    Manik Surtani wrote:

     

    Second one - this I sincerely did not get what you meant... while designing I saw that we had two paths to take:

      1st: assume the ID for the cache is the same as for the entity and give users means for looking up the cache by the id.

      2nd: let the user specify either the regular key or a natural immutable key (gives greater flexibility but increases store complexity a lot)

    Yes, but a simple entity ID may not be enough.  Consider that I have 2 entities: Person and Address.  Person's ID is an autogenerated long.  Address's ID is an autogenerated long.  So what should cache.get(5L) return you?  A Person or an Address? 

    It'll depend on which was the root entity mapped to the cache... the user would have the option to map either the Person or the Address and the one mapped would impose how the user could retrieve items from the grid. The only drawback is that suppose we had shared addresses between Person instances... we would end up having it duplicate since after serialization the cache would probably end up having separate instances for each person instance.

    Manik Surtani wrote:

     

    Third one - I was really uncomfortable with this expiry time in my store impl since at first I was thinking of providing means for the user to have a fast access layer to persistent entities through infinispan... something like seeing Hibernate the other way around. This way, we cant assume the user will have a timestamp field in its entity that we can use as a expiry time since we are talking about entities... do you think this violates way too much what loaders are for? Sincerely... I see a huge room for applications on top of this idea (there are a miriad of huge volume transactional applications today that needs a super fast storage area for looking up additional processing data).

    Absolutely.  Perhaps you could provide an additional annotation to annotate any arbitrary field or getter to retrieve expiry information from an entity.

    That is a possibility...

    Manik Surtani wrote:

     

    Fourth and last one: I thought about having each loader serving a single entity (or an entity hierarchy).

    You mean 1 cache per entity/entity-hierarchy.  Makes sense, and steps around the problem if IDs I described above.  But this should be optional - people may still want 1 cache for all entities.

    I dont feel like this makes much sense for this particular loader approach... I see what you mean that we are kinda limiting the possibilities of a cache based on this loader but for now I dont see any workarounds... I'll try to analyse this deeper to see if there is any possible resolution...

  • 17. Re: CacheLoader w/ JPA or Hibernate backend
    Manik Surtani Master

    BTW do you want to take on ISPN-31?  Perhaps assign it to yourself, and make notes of your findings, research, designs, etc there?

  • 18. Re: CacheLoader w/ JPA or Hibernate backend
    Rafael Ribeiro Novice

    Manik Surtani wrote:

     

    BTW do you want to take on ISPN-31?  Perhaps assign it to yourself, and make notes of your findings, research, designs, etc there?

    Sure... Can I assign myself or do you need to assign it since I saw it is currently assigned to you?

  • 19. Re: CacheLoader w/ JPA or Hibernate backend
    Manik Surtani Master

    You should be able to assign it to yourself.

  • 20. Re: CacheLoader w/ JPA or Hibernate backend
    Rafael Ribeiro Novice

    Hi Manik,

    Manik Surtani wrote:

     

    You should be able to assign it to yourself.

    I guess I dont have the permissions needed for assigning it to myself since I could only see the following action buttons: "comment", "attach file" and below "more actions": "attach screenshot", "add vote", "watch issue", "create sub-task", "link" and "clone".

  • 21. Re: CacheLoader w/ JPA or Hibernate backend
    Manik Surtani Master

    Ah, that's because you were not in the "developer" group for Infinispan.  Added you to the group and assigned it to you.

  • 22. Re: CacheLoader w/ JPA or Hibernate backend
    Rafael Ribeiro Novice

    Manik Surtani wrote:

     

    Ah, that's because you were not in the "developer" group for Infinispan.  Added you to the group and assigned it to you.

    Fine! I'll try to have a look at this in the following weeks... and also to consolidate what we have discussed so far in the JIRA.

    Stilll while we are deciding on the approach to take I'd like to hear your opinion about having an approach to slicing the entities to be loaded in a way similar to this one:http://www.percona.com/ppc2009/PPC2009_mysql_pagination.pdf. I think that since an Entity must have an ID field an since every id field can be ordered (either it is an integer or a char sequence) we could use the approach described which would in turn provide an efficient way of loading and not dependent on any other proprietary SGBD feature apart from the rownum from Oracle (or any other similar that the majority of SGBDs support).

  • 23. Re: CacheLoader w/ JPA or Hibernate backend
    Manik Surtani Master

    Hmm, wouldn't that mandate an additional field on user types though?

  • 24. Re: CacheLoader w/ JPA or Hibernate backend
    Rafael Ribeiro Novice

    Hi Manik!

     

    Sorry for taking that long to reply but I was in the middle of a loooong process... moving from one state to another here in Brazil... and it was from southeast back to northeast... but anyways... I am now kinda established...

     

    Anyways... back to our discussion ...

    Manik Surtani wrote:

     

    Hmm, wouldn't that mandate an additional field on user types though?

    I dont feel like it will mandate an additional field... I am only thinking about picking that option of forcing the entity ID as the cache ID and this method - as described on Yahoo presentation - would only be applied to provide an efficient slicing of the entities... so that in each slicing we would pick for example 1 thousand entities and on the next load iteration would then pass the id for the last loaded entity and specify again that this should pick at most another 1 thousand entities... This (as described by Yahoo) would be better handled by the SGBD than a start by row (something like the skip clause some SGBDs present) and also better than the first attempt I did (using the in clause with a list of ids... that is limited for example on Oracle).

     

    best regards,

    Rafael Ribeiro

  • 25. Re: CacheLoader w/ JPA or Hibernate backend
    Manik Surtani Master

    Ok, well if it works for you I'm happy to accept a patch or a prototype and try it out.

1 2 Previous Next