Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Offline processing  RSS feed

 
Yo Japs
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A J2EE application processes requests from the users and performs certain task.

- Each request comprises of several sub-tasks which are invoked one after the other. The application context object is updated each time the sub-task is through with the job.
- At the end of processing the request, the application context object contains the overall result of the processing done.
- The context object is then processed further to extract the key details of the result and the record is stored in a database. The result is then sent back to the user.

As evident from the points mentioned above, the processing of the context object does not add much value as far as the processing the user request is concerned. The application performance should improve by good amount if the step of DB insertion is done later asynchronously.

Any views on which should be the most optimised way to achieve this (saving the application context object). Should writing to the disk be performant as compared to the DB insertion?

Thanks in advance for your views/suggestions/comments.

Cheers,
Yogesh

PS: The application is supposed to process approx 1,20,000 requests in a day & hence application response time is a prime requirement
 
Paul Sturrock
Bartender
Posts: 10336
Eclipse IDE Hibernate Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Persisting the state of your application asynchronously is fine, so long as your application can tolerate the much longer transaction time. If you know for certain that the data you are persisting "off-line" is not shared with any other user and cannot be updated in any other way, then you are probably OK doing this. You will also need to ensure that either your application can tolerate some lost updates or you have some additional recovery mechanism should your application fail before it can persist its state.

Remember that the file system is not a transactional resource, so though its performance may vary from a database more fundamentally it is a different type of persistant store than a database. Also remember that you cannot directly access the file system in a distributed environment (or at least there is no easy way to do this).
 
Yo Japs
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Paul,

First of all, Many thanks for your time and suggestions. Here are a few more details about the 'data'.

- The data in question is the result of the processing done by the application in response to the user request. The user gets the response synchronously. However, the result is also stored in a Database as a historical data.
- While processing the user request, such historical data (according to the type of request) is checked by the application. As far as the functionality is considered, the application should be quite OK if there is a small error in the historical data. Nothing would go wrong if it is not 100% correct.
- The reason to look for means making it asynchronous is solely to save some processing time.

With the above inputs, could you suggest some efficient ways of achieving the objective.

Thanks in advance.

-Yj
 
Paul Sturrock
Bartender
Posts: 10336
Eclipse IDE Hibernate Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So this is less application data than a log? Have you considered log4j's JMS appender? Or is it too simple for your requirements?
 
Yo Japs
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sorry, I have not used/checked the log4j JMS appender. It would be helpful if you could provide some pointers as to how it may be helpful for my requirement.

Regards,
Yj
 
Paul Sturrock
Bartender
Posts: 10336
Eclipse IDE Hibernate Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, you are the person best placed to understand your requirement, but a JMS appender will JMS to write a log asynchronously. Does this fit what you need?
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I guess you have already measured your database update time carefully to make sure this is worth the complexity and risk.

To the overall concept, I've done this kind of thing before to speed up user response. Error handling was usually the biggest challenge. In one case, we put items into a "headless" processing queue, meaning no user attached. If the process failed, it put the items into another queue for human review, editing, and another try at saving. Putting items in a queue is not free; the process had to be fairly beefy to make this worth while.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!