permaculture playing cards*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Client crash problem 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 "Client crash problem" Watch "Client crash problem" New topic
Author

Client crash problem

Tiny Star
Greenhorn

Joined: Jul 29, 2002
Posts: 16
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?
Michael Morris
Ranch Hand

Joined: Jan 30, 2002
Posts: 3451
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


Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius - and a lot of courage - to move in the opposite direction. - Ernst F. Schumacher
Tiny Star
Greenhorn

Joined: Jul 29, 2002
Posts: 16
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

Joined: Jan 30, 2002
Posts: 3451
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

Joined: Jul 29, 2002
Posts: 16
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

Joined: Jan 30, 2002
Posts: 3451
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
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Client crash problem
 
Similar Threads
myThread.isAlive() v.s. WeakReference ? URLyBird 1.2.2 using Socket
Fbn question about design
Connection Object for lock/unlock...?
where to put bookflight() question
Input Validation