1

I'm working on a task where application uses some configuration from database. Configuration is being stored in java persistent object. On server start Hibernate session gets created and all configuration data is loaded into object with lazy load option. Same object is used by concurrent user requests.

Structure of config data:

Config DB structure

workflow: Workflow

for. eg. Person person is a hibernate entity. (java persistent obj.)

person object gets loaded with hibernate get list call on server start. Only one sessionfactory and session is initialized. DAO has only get call.

On subsequent server requests person object is accessed for its properties.

In general I am not sure how this setup will work for multiple and parallel server requests.

1) Keeping session open for long; will it cause any issue? 2) Is it a good practice? I understand session should be closed after each CRUD operation. But specifically for above workflow what should be the right approach. 3) Can multiple server request access the same persistent entity? (only get calls)

Looking for some guidane and help. Any inputs associated with design and performance.

Neil Stockton
  • 11,383
  • 3
  • 34
  • 29
pratikpawar
  • 2,038
  • 2
  • 16
  • 20
  • So, you're storing users and configuration in a database, but they will never be modified or deleted? They're completely read-only? And there are so few of them that you can keep them in memory forever? – JB Nizet May 26 '15 at 20:19
  • @JB Nizet Yes. But its not users informations. It is configuration data of questions on UI. Each question (jsp element) has list of answer, each answer may or may not have question group. Question group points to list of questions associated with that answer. There are around 1000 Qs, 250 answers and 250 groups. Not all questions will have answers. – pratikpawar May 26 '15 at 20:52
  • @JBNizet I can make db call as and when require but im unsure about performance on UI. Each user action on UI triggers next set of questions to be visible on UI and it should do so within 1~2 secs. – pratikpawar May 26 '15 at 21:01
  • I personally think that loading everything on server startup and caching the information is premature optimization, that will do more harm than good, and make things more complex when you'll have more than a handful entities. Do the simplest thing, avoid caches, use one session per request, and load what you need when you need it. Since there are so few entities, loading them should be very fast anyway. Databases are good at querying and loading data. They have their own cache. 1-2 seconds is an eternity. It shouldn't take more than a few milliseconds to load what you need from the database. – JB Nizet May 26 '15 at 21:03
  • @JBNizet Thank you for your thoughts on this. I will implement it for db calls. And will update the thread accordingly. Other concern with db calls is each time any user opens up UI for create, edit or view there will be around 1000 calls. – pratikpawar May 26 '15 at 21:22
  • I don't understand. Don't post code in comments. Explain what you're trying to achieve *in your question*. – JB Nizet May 26 '15 at 21:42
  • @JBNizet I have a recursive function which reads Q->A->Group(List of Questions) hierarchy. This is done for every user action on UI. For. e.g changing answer from Yes to no on Radio button etc. For edit of a record this recursive function gets triggered all almost 600-700 questions. im just confused with approach whether to have so many db calls (read only) for each mouse click vs caching. – pratikpawar May 26 '15 at 21:51
  • As I said, I don't understand the use-case. So maybe caching is the answer, maybe smarter queries are the answer, maybe a design change in the model is the answer. What scares me with your caching strategy is that it doesn't scale. But if you set is never going to grow, and if the entities are read-only, then read everything in memory. I just wouldn't store entity instances in memory, and even less leaving the session open. Since it has to be accessed by multiple threads, you should have an immutable, and thus thread-safe model in memory. – JB Nizet May 26 '15 at 22:38
  • @JBNizet I ended up fetching all the config data on server start and storing it in application session to meet application requirement; UI response time to be less than a second. Thank you for taking out time on this. – pratikpawar Jun 09 '15 at 10:05

0 Answers0