• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

NX:Reading/Writing DB file vs. Caching

 
Ranch Hand
Posts: 48
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi All,
I see two alternatives about handling DB file.
1- For each request reading/writing DB file and do all actions on the file.
2- Cache the DB in memory and whenever necessary write cache contents in DB.
The latter is more interesting for me since
A- Search actions would be much easier rather than dealing with the file
B- For every update I would create a thread to do the task.(How ?)
What do you think ? Any point I'm missing ?
 
Ranch Hand
Posts: 555
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Ulvi,


A- Search actions would be much easier rather than dealing with the file
B- For every update I would create a thread to do the task.(How ?)


I personally use cash, but not because of the reasons mentioned by you.
I use cash for better performance. Drawback is memory overhead, but memory is cheap.
A. Search actions would be easier, but other issues could become a bit more complicated (e.g. synchronitazion), depending on your design. So my personal opinion is , that using cash just to have more simplicity, is not an important reason.
B. It depends on your design. I do not create any threads by myself (I use RMI Server and it does create by itself). Could please describe your design that I could understand better your question.
Regards,
Vlad
 
ulvi ugur
Ranch Hand
Posts: 48
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Vlad,
Right now I am actually trying to design the whole thing. My current thread is about the class which is going to be used by the server(and GUI in stand-alone mode). At this stage I don't think that I need to make a decision about the communication between the client and the server. (Although I am very interested what the factors for you to use RMI are)
My point about caching when I say "simple" is so :
1- If I synchronize all requests (search/update/delete) then I would prevent dirty reads. Might be difficult to implement but easier to understand.
2- For search operations, I don't need to read the file again, I only need to search in the recordset I already have.
What do you think ?
 
Vlad Rabkin
Ranch Hand
Posts: 555
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Ulvi,


1- If I synchronize all requests (search/update/delete) then I would prevent dirty reads. Might be difficult to implement but easier to understand.
2- For search operations, I don't need to read the file again, I only need to search in the recordset I already have.



1. You can synchronize all requests without caching.
2. Agree
So, the point is performance, not simplicity.
I use RMI, because it hides network protocol from implementation. So it is easier for me and for somebody who wants to understand business logic of my program, instead of technical details.
Disadvantage is: I do have poor control over the thread creation for remote clients, but I designed my program so, that it doesn't care about it.
Regards,
Vlad
 
reply
    Bookmark Topic Watch Topic
  • New Topic