• 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

Client crash problem

 
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I see that someone says that we must consider
the client crash problem but i think if you only
call RDBinterface.book() at client side and implement it at server side
public void book(){
lock()
modify()
unlock
}
you will not need to consider this problem , am i right ??
so such as client id etc. is no need?
 
Ranch Hand
Posts: 3451
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Tiny,


...
public void book(){
lock()
modify()
unlock
}
you will not need to consider this problem , am i right ??


It would seem that that would prevent a client from holding unlocked records in the event of a crash. The only problem I see, and it may be unworthy of consideration, is if the server crashes or the network connection is lost during the book() invocation. How will the client know what state the transaction is in? Do you assume a failure in the booking operation? That would not always be the case. But as I said that may not be worthy of consideration since it would be a very unlikely event.
Michael Morris
 
Tiny Star
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hi Michael,thanks very much for your post.
But someone says we should put the bookflight(int flightnum) logic at client side and the server is just a database server provides no business logic
so the call of lock() modify() unlock() are all at the client side , so if clientA call lock(int rec) but before he call unlock() he crashes so the record on the server will never be unlock,
the others can not book the ticket of the flight
is this not a serious problem?? i mean client crash not server crash!
waiting your reply!
 
Michael Morris
Ranch Hand
Posts: 3451
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Tiny,
As I explained in another post of yours, you can have your Remote connection object implement the Unreferenced interface (provided that you are using RMI as a network transport) which will take care of the client crash problem. It may take up to ten minutes or more to do so though.
My opinion is that the business logic should be on the client also but others have chosen to put it on the server. The ultimate decision is yours but you should provide good arguments for doing so in your design choices document.
Hope this helps,
Michael Morris
 
Tiny Star
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks very much!
I'm now knowing that the business logic can put at both client side and server side but why?

I cann't give the resean,both way are all right.
Someone told me that the server is only a database interface and this would be a good reuse
.
But i cann't understand this.i think if the client side logic will be changed some days later
every client must download the new client but if we put it at server ,client is no need to do anything! am i right ? or i miss thing? i really want to know how they explain thire design who put bookflight() at client side.
can you tell me ?
 
Michael Morris
Ranch Hand
Posts: 3451
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Tiny,


But i cann't understand this.i think if the client side logic will be changed some days later
every client must download the new client but if we put it at server ,client is no need to do anything! am i right ? or i miss thing? i really want to know how they explain thire design who put bookflight() at client side.


If you only have primative operations on the server, then you can create different types of clients to connect to the server. For example, our client has no need to use the add() or delete() methods of the public Data interface. But we might (and probably would) want an administrative client that could delete old records, add new ones, and modify some exitsting records. If only business logic were on the server, we would then have to modify the server code as well as write the new client code.
This really all comes down to one fundamental question: What do you, the developer, feel are the responsibilites of the server? Of course, if we were writing a three-tier application this would be an easy question since the business logic would go in the middle tier. I would suggest that wherever you put the business logic, that you do it in such a way that it would be a simple matter to change the application to a three-tier application. Most of us have used the Facade pattern on the client to translate the business logic into primative calls. That will allow you to create a middle tier at some point without too much alteration to the client and no alteration on the server. But it could work the same the other way around.

Hope this helps,
Michael Morris
 
Evildoers! Eat my justice! And this tiny ad's justice too!
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic