This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Writing records from cache back to data file. Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Writing records from cache back to data file." Watch "Writing records from cache back to data file." New topic
Author

Writing records from cache back to data file.

Sean Keane
Ranch Hand

Joined: Nov 03, 2010
Posts: 581

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?


SCJP (1.4 | 5.0), OCJP (6.0), OCMJD
Sean Keane
Ranch Hand

Joined: Nov 03, 2010
Posts: 581

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?
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5139
    
  12

That's an easy one: Runtime.addShutdownHook to the rescue


SCJA, SCJP (1.4 | 5.0 | 6.0), SCJD
http://www.javaroe.be/
Ahmad Saleh
Greenhorn

Joined: Dec 17, 2008
Posts: 4
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.
Matthew Brown
Bartender

Joined: Apr 06, 2010
Posts: 4344
    
    8

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

Joined: Nov 03, 2010
Posts: 581

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
Bartender

Joined: Jul 19, 2004
Posts: 5139
    
  12

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

Joined: Nov 03, 2010
Posts: 581

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
Bartender

Joined: Jul 19, 2004
Posts: 5139
    
  12

Every assumption you made is correct.
Sean Keane
Ranch Hand

Joined: Nov 03, 2010
Posts: 581

Super! It's all coming together now! Thanks
Oladeji Oluwasayo
Ranch Hand

Joined: Sep 10, 2010
Posts: 101

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.


OCPJP 6, OCMJD 6
Sean Keane
Ranch Hand

Joined: Nov 03, 2010
Posts: 581

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 .
 
Don't get me started about those stupid light bulbs.
 
subject: Writing records from cache back to data file.
 
Similar Threads
Should lock methods be callable by the client
URLyBird GUI start up how to get all Rooms?
nx:All of URLy Bird1.1.3 about record lock
Cache in Data Class
URLyBird: 2 questions