• Post Reply Bookmark Topic Watch Topic
  • New Topic

Criteria search on rapid changing objects  RSS feed

Cristian Vrabie
Ranch Hand
Posts: 71
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi guys, I'm not sure this is the best place to post this but I have this problem that's been bothering me for a long time, and I would really appreciate it if some of you can come with some ideas.

So, in a http service server, I have this class Entity wich has a lot of properties (let's call them a, b, c, d, ....) that are spread across multiple tables. A worst case scenario estimate would say that at one time there can be 10,000 entities with a lot of read operations on them. Client apps can iterogate this server via http calls wich contains queries like: ["and",["eq","a",10],["or",["gt","b",7],["lt","c",15]]]. You get the idea: it's a json encoded string that would traduce into (a==10 && (b>7 || c<15)). It's really easy to traduce this query string into a hibernate criteria find. No problems till now.

The turning point is that 2 of these many properties (let's say: a and b) need to be updated really often, by a server script. A worst case estimate would say that there can be as many as 1 write per second for 20% of all entities, meaning 2,000 changes per second. You can ofcourse note that it's imposible to sustain so many operations on the db. To cache all entities in DB would solve this but it's not possible because as I said Entity has a lot o properties wich would result in a lot of memory consumption. The solution I chose now is to only cache a map of the Entity id with a small object containing the 2 properties that need to be updated very often. Now the writes are no problem but you can see that the query can no longer be directly traduced to a Hibernate criteria.

What I do now is to first query the component that knows the true values of a and b and transform that in a restriction like ("id" in [list_of_ids]), merge it with the other restrictions refering properties stored in db, then make the actual db query. The problem is that a restriction like a>10 can result in hudge list of ids (maybe all of them) wich (i guess) would be higly innefective in a db query. Another secondary effect is that the component that knows a and b (and updates them has to be coupled with the service for entity. Every time you create/delete an Entity you have to notify that component.

Isn't there any other, more elegant, solution? Maybe Hibernate cache can help somehow? (thow i never heard of caching only some of the properties). I would go as far as writing another cache mechanism for Hibernate if I need to
What do you think? Do you have any ideas for my tricky problem?
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!