Here are several points: 1. L2 cache may not contain all entries and query result may be inconsistent (to say the least) with DB. 2. Join queries over L2 cache are very questionable - data consistency, colocation are very hard to guarantee. 3. Maybe it is better to use query cache? 4. Or completely switch to key-value API with Hibernate store implementation?
Thanks! --Yakov 2015-05-29 3:38 GMT+03:00 Alexey Goncharuk <alexey.goncha...@gmail.com>: > Igniters, > > I was playing with Hibernate L2 cache and came across this limitation: even > though user entities are formally stored in Ignite cache, they are stored > in form of Hibernate CacheKey and CacheEntry, which makes it impossible to > use Ignite query mechanism over cached data. > > On the other hand, all the required information to enable such queries is > either present in CacheEntry itself (such as field values and type name) or > can be obtained via Hibernate persister metadata. Since SessionFactory may > not be available on server nodes, we would need to store persister metadata > in a system cache first to make it available for indexing. > > The idea still needs quite a bit of research, because currently we require > the structure of all the indexed types by the moment of cache creation, > however, given the ability to create caches on the fly, I think it is still > possible to implement and it will provide a great benefit and ease of use > for Hibernate users. > > I summarized my thoughts in this ticket: > https://issues.apache.org/jira/browse/IGNITE-952 > > Thoughts/comments? > > --AG >
