• 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

Writing records from cache back to data file.

 
Ranch Hand
Posts: 590
Eclipse IDE Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I've read of many people who have created a BusinessService interface which allows the client to interact with the database. In the BusinessService interface two operations are mentioned - one to search and one to book. Now, for people who have used a cache in their data class how do they ensure that the records in the cache are written back to the data file?

When running in standalone mode the records in the cache should be written back to the data file when the user closes the application. But the application is only able to communicate with the database indirectly through the BusinessService interface. If this interface only has two methods (one to search & one to book) then there is no possible way for the application to call the method on the database that writes the cache back to the data file.

The benefit of the BusinessService interface is that in your client code you can treat the local and remote service as being the same. So exposing the method that writes the cache back to the file in the BusinessService inteface would not make sense in general.

It would make sense for the local mode. Because in the local mode we want the client to execute the method that writes the cache back to the file. But when the client is running in network mode then we definitely don't want the client to be executing this method - it makes no sense for the client to be telling the database to write the cache back to the file, this is the job of the server to do.

How have people handled this situation? To me the only way I can think of is to expose the method from the database class that writes the cache back to the file. I must be missing something here, because this is definitely not how others have done it. Because others using a cache have mentioned that they have only got book\find methods in their BusinessService interface.



Any ideas?
 
Sean Keane
Ranch Hand
Posts: 590
Eclipse IDE Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Looking at Robertos solution in the paper that he wrote he has a method called saveData() in this Business Service class. Obviously this will work. But it makes no sense in the context of the client running in network mode.

Surely you would not want to allow the client running in network mode to write the cache back to the file. In order to prevent this, you would need to introduce a test somewhere in the client to either check what mode the client is running in, or check the underlying class of the instance of the business service you have. Neither which seem nice:

Of course these two solutions are just stopping the client from attempting to save the data when running in network mode. There is nothing to prevent a developer coming along at a later point and writing code that attempts to save the data when running in network mode.

So back to my original question. For people who only had two methods in their Business Service interface, how did they handle writing the cache back to the data file when running the client in standalone mode?
 
Sheriff
Posts: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
That's an easy one: Runtime.addShutdownHook to the rescue
 
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Sean Keane wrote:
Surely you would not want to allow the client running in network mode to write the cache back to the file. In order to prevent this, you would need to introduce a test somewhere in the client to either check what mode the client is running in, or check the underlying class of the instance of the business service you have. Neither which seem nice:



I can't see a big issue in allowing the client to save the data on the file.
In my implementation, I allowed the clients to save the cached data (it is always saved on a client's shutdown) and I gave the user the ability to save the data anytime while running the client from the menu item.
The only side effect that I don't like is that when a client saves the data, it saves all clients' changes (not only its own), its not so bad side effect though.

I'm actually against records caching, but Oracle's interface is restricting me.
 
Bartender
Posts: 4568
9
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I used Roel's approach. A key part of my design is that the server component should have no idea what mode it's running in. Any saving strategy that depends on the mode is a poor design, in my opinion.
 
Sean Keane
Ranch Hand
Posts: 590
Eclipse IDE Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Roel De Nijs wrote:That's an easy one: Runtime.addShutdownHook to the rescue


Yes, that is the approach that I was going to use. But I looked at Andrews code and he only uses the shut down hook in the server. He sets it up in the GUI code for the server. This had me thinking that I should set it up in my GUI. After some sleep , now I think I see where my thinking was going wrong.

I need to set up the shut down hook in one location. This one location needs to be common to both the standalone and network mode. So the client GUI is not the place to set it up - someone could shutdown the server! The place that is common to both is where the database is created. So in the code that creates my database I should add the shut down hook at this point.

In implementation I have a DAOFactory which returns an instance of the database. So I have:
So the getDbManager(final String databaseLocation){} method is really the only logical place where I could add the shut down hook I think.

I could use the getDbManager() method to get access to the database in another location. This would allow me to add the shut down hook somewhere else and allow me access to the database directly to call the method that saves the cache back to the file. But I can't think of anywhere else that would be appropriate to add the shut down hook.

Where in your code did you actually add the shut down hook Roel?

I'm guessing you extended the database interface provided to include a method that writes the cache back to the file and you did not expose that method in your Business Service? So in your shut down hook you would be interacting directly with a database object and not through the Business Service. Am I correct?
 
Roel De Nijs
Sheriff
Posts: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Sean Keane wrote:Where in your code did you actually add the shut down hook Roel?


Data class constructor (so no need to expose the method in the business service)
 
Sean Keane
Ranch Hand
Posts: 590
Eclipse IDE Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Roel De Nijs wrote:

Sean Keane wrote:Where in your code did you actually add the shut down hook Roel?


Data class constructor (so no need to expose the method in the business service)



That is interesting. Am I correct in thinking that you added the method that saves the cache back to the data file into your interface that extends the provided DB interface?

If you have added your shut down hook in the constructor of the Data class then there would be no need to expose this method in the interface?

Of course you could have exposed this method in your extended interface not for your purposes but to allow someone in the future to call this method e.g. if someone were to implement periodic writing of the cache to the data file?

 
Roel De Nijs
Sheriff
Posts: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Every assumption you made is correct.
 
Sean Keane
Ranch Hand
Posts: 590
Eclipse IDE Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Super! It's all coming together now! Thanks
 
Ranch Hand
Posts: 101
Netbeans IDE Oracle Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Actually, I kept my database consistent with the cache as the aim of my cache was solely to optimize SEARCH and READ operations (properly documented in my choices.txt) because I expect so many searches from the numerous clients before a booking will actually be made (lets imagine a real-world scenario please). All WRITE operations update the cache and database accordingly (keeping them both consistent. What happens when a toddler of one of URLyBird workers manages to get to the system and pushes the power-off button, no shutdown hook will be executed!)
But to provide for future modifications (where probably WRITE operations only update the cache), I provided method dumpCacheToDatabase() in my extended interface. This method can be invoked to write the cache back to the database at anytime.
 
Sean Keane
Ranch Hand
Posts: 590
Eclipse IDE Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Oladeji Oluwasayo wrote:What happens when a toddler of one of URLyBird workers manages to get to the system and pushes the power-off button, no shutdown hook will be executed!



Yep, that is one of the drawbacks of using a cache in this way. I will of course be documenting this in my choices. However regards this certification, I think Roel passed with 100% and he adopted this approach too, so it should be safe enough for passing .
 
reply
    Bookmark Topic Watch Topic
  • New Topic