Hi,
I take it that everyone has to concern themselves with increasing their
file size? That is, even if you don't add any new physical records to
your file in response to a user interface interaction, you still create the
implementation code to increase the file size?
This is one topic I have yet to see discussed in this news group. Any
suggestions on search strings I might use? I've tried "increasing file size"
with no hits.
In my first draft, since I will not be exposing Data to my clients, I will
use an unsynchronized ArrayList, where each element of this collection
is my version of a MUTEX object.
Does anyone have any ideas on how to grow the unsynchronized ArrayList?
Or, is this covered in any kind of design
pattern I might read about?
One idea, using "chemicals to change the behavior of the mutex-like object"
using the observer-obervable
Java feature I outlined here:
https://coderanch.com/t/185034/java-developer-SCJD/certification/Design Another idea, which I thought of after writing the above post, was to
say that instead of NLock being an ArrayList of mutex-like objects,
if would be an ArrayList of an ArrayList of mutex-like objects, where
each sub-ArrayList would hold, say, 1,000 records. However,
this simply delays the problem! For if the file gets big enough, eventually
the ArrayList holding the other ArrayLists has to grow, and then you use some
method to wait for the threads to leave it, block incoming threads, and the
like, i.e., get one lock on the complete object, before increasing its size.
So, I find this an interesting problem. And, I'm curious if you all might
be able to define the problem domain this is in so that I might study it:
that is, the design pattern problem, or any other design ideas addressing
how to grow the size of an unsynchronized ArrayList.
From this article
https://coderanch.com/t/185034/java-developer-SCJD/certification/Design is where the implementation steps were outlined:
1. Stop all incoming threads to NLock and get them to wait around until told
to run.
2. Wait for all threads currently using NLock to complete.
3. Finally, when no
thread is using NLock, send one thread in to carry out the
newWrite operation which will add a record to the RAF and add an element to the
ArrayList NLock.
4. When done, allow all those threads waiting to get access to NLock to proceed.
In short, this puzzle is not related to how to lock down the physical, database,
random access file (that's simple, synchronize all the methods in MicroData);
the puzzle is how to lock down an unsynchronized ArrayList.
Besides my two solutions above, are there others? There must be, I hope,
as the problem is tricky enough that someone brighter than me must have
solved it. I'm not complaining about my solutions above, but having thought
about this, it's always satisfying to then see how a master solved it, to complete
the learning experience.
Thanks,
Javini Javono
.
