• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

NX: Synchronization of file access & no caching

 
mike acre
Ranch Hand
Posts: 197
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I was thinking of having my data access organised as follows

1 RAF
Multiple Data access to this RAF via the supplied interface. 1 thread per instance.
No Cacheing - to KISS

I understand the need to synchronise access to the RAF for my multiple threads requiring access.
AFAIK the reason for locking at the record level is to improve performance so that data flow is only restricted where necessary.

Is this last point's advantage nullified due to the fact that I am not going to cache records? Since essentially operations are synchronised at the RAF level - no matter what record is being accessed ie a seek/read or seek/write.

If I used caching then record locking's advantages would be realised.

As far as I can see, if I don't use cacheing then the advantages of multithreading are less useful, though obviously a lot of stuff can be done before the bottleneck of the RAF itself. And the locking at record level has no performance gain.

I know performance is not the issue with SCJD but I just need to get my thinking straight.

Please put me straight someone.
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12007
215
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Mike,

The synchronization on the RAF and the logical record locking have quite different purposes.

You are right in that you need to synchronize on the RAF to ensure that only one thread is accessing the file at any given time.

But booking a record has a totally separate issue: ensuring that only one client books the record. This requires your booking process to check that the record is still available to be booked, and then book it. Since there are two steps involved here, you need some way of making sure that no other thread can book your record in between those two steps.

To make this a bit clearer, we are talking about two threads (A and B) both trying to book the same record:

  • Thread A checks that the record is still available
  • Thread B checks that the record is still available
  • Thread A books the record
  • Thread B books the record



  • Now you could avoid that by putting the booking code inside a synchronized block. However:
  • This reduces concurrent access to your database, as only one client at a time can be doing bookings
  • This assumes your booking method is in the database server logic. If your booking method is in the client software, you cannot do this. This is not an argument for where the booking logic should be though - see the long thread "Should lock methods be callable by the client" for arguments about where the booking method should be .

  • The better way of handling this is to use logical record locking around your booking code. Then as long as one client owns the lock, it knows that no other thread can lock it.

    Returning to my earlier example of the two threads trying to update the same record:

  • Thread A attempts to lock the record - succeeds
  • Thread B attempts to lock the record - goes to wait state
  • Thread A checks that the record is still available
  • Thread A books the record
  • Thread A unlocks the record
  • Thread B attempts to lock the record - succeeds
  • Thread B checks that the record is still available - cannot book record
  • Thread B unlocks the record



  • Regards, Andrew
     
    mike acre
    Ranch Hand
    Posts: 197
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Thanks for the response Andrew, I'm afraid I can't have put myself well, I understand the points you make.

    The thing I want to get straight is really a performance one rather than a logical one. I know performance isn't out concern, but I'd like to get it straight anyway.

    The points you make aside, the reason we lock on the record as opposed to the whole database is a performance one. Access to the data is synchronised, since there is just one source of data. This is ultimately where all threads converge. So this is likely the bottleneck. The fact that a record is locked is immaterial because if the client wants to update then the operation to do that at the back end locks the whole database.
    I realise the point of multithreading is that everything else can be completed in tandem, but at the end they must all queue up and take there turn at the data.

    I guess this is the 1st time I've rubbed my nose in the mechanics, and before (JDBC / Access etc) The notion of a record lock meant minimising resource restrictions.

    The answer I'd like now would be something like: the actual RAF operations are actually lightening fast and all the other stuff that is done multithreaded does actually take most of the time.

    Or maybe this has revealed a major flaw in my thinking. Please put me straight!

    TIA
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic