Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Buffering and Locking

 
Omar Kalaldeh
Ranch Hand
Posts: 58
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,

I want to discuss the following tow issues:

1)I am buffering record data on memory using some kind of collection.
And since we are talking about small number of records tens or maybe as max few hundreds, I find this approach acceptable and offer time efficacy.

2)Lock/Unlock, until now I am not sure where the locking operation should be initiated, from the client side or server side. Although I am preferring it to be at server side and just before performing any update operation(delete, update), as flowing (lock >> update >> unlock), and that due to the following reasons :
-It�s more efficient to lock the record before use it then unlock, it will take less than a second.
-Clients can make search on whole data locking the whole database, which create a series efficacy problem.
-It�s simpler; you don�t have to keep an eye on the clients.

Why not:
-maybe a client will search the DB for a record, as a return result, he find the record is not booked, so he perform a booking update, but at the same moment there is another client performing the same operation, and so one of them will get failed. So is this acceptable to return a free record in search and return already blocked on the update.
I have to mention that the read and search methods on DB interface don�t check for locked records, I know I can go around this problem, but still should I.
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12014
220
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Omar,

Welcome to JavaRanch and this forum.

There are many other people here buffering or caching their records. But I didn't see a question from you regarding it - are you trying to find out if it is acceptable or are you trying to find out potential problems or ???

As for locking client side / server side, you may be interested in reading the (long) thread "Should lock methods be callable by the client" which will probably give you more arguments both for and against locking either way than you probably wanted to read .

Regards, Andrew
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Omar,

Welcome to this forum and JavaRanch! (OK, it looks inverted and it's not my normal way of welcoming people here, but I wanted a slight different phrasing than Andrew in this thread ).

Andrew:
As for locking client side / server side, you may be interested in reading the (long) thread "Should lock methods be callable by the client" which will probably give you more arguments both for and against locking either way than you probably wanted to read .


I totally agree with Andrew.

I'd just want to add:

  • that in the meantime published scores have proven than both solutions (badly called "2-tiers" vs "3-tiers" in that thread) are equally accepted by SUN;
  • that I like your arguments under 2) above, but that it's personal.



  • Best regards,

    Phil.
     
    Omar Kalaldeh
    Ranch Hand
    Posts: 58
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi Andrew and Phil.

    Thanks for yours reply , and I am glade the 3-Tires module is accepted by sun. Now I am defiantly going with the it.

    I really enjoyed reading the thread "Should lock methods be callable by the client"; in fact I wished if I participated in that great discussion.

    Best regards.
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic