• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

How to handle existing threads while shutting down the server ?

 
Kerim Kara
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi All

I am a new to javaranch and thank you everyone caring to read , hopefully answer too.

I am thinking about a couple concepts about developer certification assignment ?

1) how to handle waiting, running threads when server is shutdown ?

and another on more basic

2) is Data.class a part of server or database, in other way in standalone mode will I need to access to Data.class or not ?

thanks
 
K. Tsang
Bartender
Posts: 3583
16
Android Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
To answer your questions

2/ Data.class is part of the database. In stand-alone mode (without server), the app needs to talk to the database (hence the Data.class)

1/ If I understand your question correctly, I believe you are talking about "shutdown hook" on the server.

Say there are several clients/users connected to the server, then you kill (Ctrl+C) the server. A shutdown hook will allow the server to tell the clients that (server) is about to shutdown in X minutes, please log out blablabla.

Hope this helps.
 
Kerim Kara
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you
K. Tsang



K. Tsang wrote:To answer your questions

2/ Data.class is part of the database. In stand-alone mode (without server), the app needs to talk to the database (hence the Data.class)

1/ If I understand your question correctly, I believe you are talking about "shutdown hook" on the server.

Say there are several clients/users connected to the server, then you kill (Ctrl+C) the server. A shutdown hook will allow the server to tell the clients that (server) is about to shutdown in X minutes, please log out blablabla.

Hope this helps.
 
Roel De Nijs
Sheriff
Posts: 10662
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I fully agree with the answers of K. Tsang
 
Kerim Kara
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
still though, why do we need locking method in single threaded environment in standalone mode ?
we lose some performance because synchronization and thread safety code in standalone mode.

is there a explanation for that one or am I missing something

Thanks
 
K. Tsang
Bartender
Posts: 3583
16
Android Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Kerim Kara wrote:still though, why do we need locking method in single threaded environment in standalone mode ?
we lose some performance because synchronization and thread safety code in standalone mode.

is there a explanation for that one or am I missing something

Thanks


Simple answer: Because Oracle is really testing whether you can develop multi-threaded applications.

For standalone mode, if you comment out the lock/unlock lines in create/update/delete methods, the app would function as expected.

Performance is a minimal issue due to today's fast processors.
 
Roel De Nijs
Sheriff
Posts: 10662
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Kerim Kara wrote:still though, why do we need locking method in single threaded environment in standalone mode ?
we lose some performance because synchronization and thread safety code in standalone mode.

is there a explanation for that one or am I missing something


Another reason: you don't want your database (Data class) to be aware of which mode the application is running in.
 
Roel De Nijs
Sheriff
Posts: 10662
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
K. Tsang wrote:For standalone mode, if you comment out the lock/unlock lines in create/update/delete methods, the app would function as expected.

The create/update/delete methods (in the Data class) should not invoke lock/unlock methods. That's a violation of the single responsibility principle. A method should have just 1 purpose. So for example the update-method should only implement the actual updating of a record not locking/unlocking the method.
 
Kerim Kara
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks to both you guys.

I'd prefer to merge Data.class functionality with Rmi server functionality and keep the database object with separate update delete find methods.
But since data class is a must for both server and standalone mode, I will keep calling lock/unlock method in only rmi server and
data class will be an interface accessing database.
 
Roel De Nijs
Sheriff
Posts: 10662
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Kerim Kara wrote:I will keep calling lock/unlock method in only rmi server

Then you'll be violating a must requirement. Because the interface you MUST implement clearly states for the lock-method:
instructions.html wrote: // Locks a record so that it can only be updated or deleted by this client.


So before you can update/delete a record, it must be locked! It doesn't matter in which mode your application is running in.
 
Kerim Kara
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Roel De Nijs wrote:
Kerim Kara wrote:I will keep calling lock/unlock method in only rmi server

Then you'll be violating a must requirement. Because the interface you MUST implement clearly states for the lock-method:
instructions.html wrote: // Locks a record so that it can only be updated or deleted by this client.

So before you can update/delete a record, it must be locked! It doesn't matter in which mode your application is running in.


what I understand,(probably wrong but still) from above instruction statement is record(given record id) can be updated or deleted by one client at a time.

Do we really need to use locking at which there is implicitly only one client in standalone mode?
 
Roel De Nijs
Sheriff
Posts: 10662
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Kerim Kara wrote:Do we really need to use locking at which there is implicitly only one client in standalone mode?

Your Data class will (or should) be completely unaware of which mode your application is running in. You should have 1 Data class which is used for both network and standalone mode.

And if your must-to-implement interface states you have to call lock before being able to update/delete a record, I would implement it like that. If you don't, you risk failure...
 
Kerim Kara
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Roel De Nijs wrote:
And if your must-to-implement interface states you have to call lock before being able to update/delete a record


my initial thought was it is not saying a lock a record for update each time, just saying make only one client edits that which is implicitly achieved in standalone mode.
 
Roel De Nijs
Sheriff
Posts: 10662
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So you will end up with 2 Data classes? One for standalone mode (not using lock/unlock methods) and one for network mode (using lock/unlock methods)?
 
Kerim Kara
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
no I was thinking 2 service classes one calls data.lock before data.update /delete an the other one just calls data.update
 
Roel De Nijs
Sheriff
Posts: 10662
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Kerim Kara wrote:no I was thinking 2 service classes one calls data.lock before data.update /delete an the other one just calls data.update

So in the update method you need to verify that the client who is updating this record was the client which locked the record (to prevent clientB from updating a record locked by clientA). But how will this check succeed in standalone mode, when you don't call the lock method
 
Kerim Kara
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Roel De Nijs wrote:
So in the update method you need to verify that the client who is updating this record was the client which locked the record (to prevent clientB from updating a record locked by clientA). But how will this check succeed in standalone mode, when you don't call the lock method


how many client can you create in standalone mode ?

it is the running client and that's all(no rmi) , isn't it ?
 
Roel De Nijs
Sheriff
Posts: 10662
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Kerim Kara wrote:how many client can you create in standalone mode ?

it is the running client and that's all(no rmi) , isn't it ?

Yes, in standalone mode just 1 client, but that's not the point at all.

Your logic in the update method must work in both modes without knowing in which mode it's running. When running in network mode you use the lock-method to lock a record by a certain client (so no other client can update this record). So when the lock-method is invoked you store the record number together with e.g. the id of the client. Then the update-method is invoked and before actually updating you must check if the id of the client trying to update this record matches with the client-id stored in the lock-method. If it is the update can safely be executed, otherwise someone is cheating.
In standalone mode you want to invoke directly the update-method. So exactly the same logic will be executed: first check if the id of the client trying to update this record matches with the client-id stored in the lock-method. But wait, the lock-method wasn't invoked, so a client-id was never stored. So the ids will never match and you can't update the record.
 
Kerim Kara
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

I think it comes to point how you perceive Data.class. it should be used by both server and standalone modes.

lock() method should be called outside of the Data.class, I totally agree on that. But to execute update regardless
of mode , you must call lock() outside of update() method, which is sharing of some responsibility of update method in my opinion.
isn't it better to preserve atomicity of method by giving the responsibility of locking to caller by exposing lock method to caller ?

By the way I am using thread ids for locking not client id, I think I need to change that.



and Roel Thank you for taking time to explain and respond promptly. I'd really appreciate that .
 
Roel De Nijs
Sheriff
Posts: 10662
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Kerim Kara wrote:By the way I am using thread ids for locking not client id, I think I need to change that.

That's an easy one: if you use RMI, you can NOT rely on thread ids. Because there is no guarantee that subsequent requests of the same client are handled by the same thread.

Kerim Kara wrote:I think it comes to point how you perceive Data.class. it should be used by both server and standalone modes.

Agreed! Data class is used in both server and standalone mode without the knowledge in which mode it is running

Kerim Kara wrote:But to execute update regardless of mode , you must call lock() outside of update() method, which is sharing of some responsibility of update method in my opinion.
isn't it better to preserve atomicity of method by giving the responsibility of locking to caller by exposing lock method to caller ?

Sorry, but I don't understand. The only thing I can add about lock and update. In my opinion lock and update should be 2 seperate, independent methods. So the update-method (in Data class) should never call the lock-method. The lock-method should be invoked prior to invoking the update-method. But the update-method still must verify if the record was locked by the client trying to update it.

Kerim Kara wrote:and Roel Thank you for taking time to explain and respond promptly. I'd really appreciate that .

Glad to hear I can help. 5-6 years ago I was the one asking the questions in this forum and I also appreciated any help/advice/hints/tips I got.
 
Kerim Kara
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you again Roel.

Roel De Nijs wrote:
Kerim Kara wrote:By the way I am using thread ids for locking not client id, I think I need to change that.

That's an easy one: if you use RMI, you can NOT rely on thread ids. Because there is no guarantee that subsequent requests of the same client are handled by the same thread.


I think it is better to set client ip to thread name and use thread name for lock check
 
Roel De Nijs
Sheriff
Posts: 10662
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Just 2 final tips for this assignment:
  • you can better have a simple, fast solution than an ultra-fast but much more complex one
  • don't forget to explain every decision you make in the decisions document (choices.txt)


  • And I'll add two examples from my assignment:
  • As client id I used something very straightforward and simple. I believe it was the current time in millis. I explained in my decisions document that although not 100% unique, it's more than good enough for this 1st version (and in one of the next versions another algorithm could be implemented to guarantee uniqueness). And of course I also explained why I couldn't use the (obvious) thread ids
  • I used an in memory cache. The main benefit is (again) simplicity. But there are also some drawbacks (power outage, big data file,...). I didn't handle all these drawbacks in code (that would be way too complex), but I mentioned them in my decisions document and also addressed possible solutions for each drawback

  • So in the end the decisions document is almost as important as your code!

    Nice to know: instead of making a "thank you" post, you could also the post(s) which you liked. It's easier, faster and other ranchers will see immediately which are the "starred" posts.

    Good luck!
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic