Win a copy of Rust Web Development this week in the Other Languages forum!
  • 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 ...
  • Tim Cooke
  • Campbell Ritchie
  • Ron McLeod
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Junilu Lacar
  • Rob Spoor
  • Paul Clapham
Saloon Keepers:
  • Tim Holloway
  • Tim Moores
  • Jesse Silverman
  • Stephan van Hulst
  • Carey Brown
  • Al Hobbs
  • Piet Souris
  • Frits Walraven

NX: Grow File Size Puzzle

Ranch Hand
Posts: 286
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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:
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
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.
Javini Javono
author and jackaroo
Posts: 12199
Mac IntelliJ IDE Firefox Browser Oracle C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Javini,
A very simple solution - document that there is the potential for problems if number of records exceeds 'x' records, and then ignore the issue .
By the time you start getting to that number of records you will almost certainly have other problems as well, and the company really should be looking at a "real" database. Having that many records in a flat file would be unwieldy in real life, and you would almost certainly want to normalize the data into several smaller tables as well as adding other functionality.
Try not to go too far with making the "perfect" solution - you may never finish the assignment.
Regards, Andrew
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
    Bookmark Topic Watch Topic
  • New Topic