[SOLVED] reader and writer on same file handle

[Nicholas Jordan]

I am working on a Servlet, I need to do file writes and file reads on the same file. Will placing two file handles on the same file cause an io exception? I can do a round-robin that places one file as read on open, another as write.append(data) on open and a third just to recover customer information such as by applet, application or just do a get operation with the browser.

Question is based on the fact that it may run locally, I need it to be reliable on server.

[Norm]

The RandomAccessFile constructor has a mode parameter that takes a value of "rw". That is the only type of file I can think of that would allow interwoven reads and writes to the same file.

[Nicholas Jordan]

I thought of that, we have a great deal of built in libs, and as well the multi-threading issue comes to the fore. That is not my question, what I am asking is say if we did a Thread crossing demo, showing two writes to a buffer and showed how it would not look really smart. Okay, I can write locks and hooks and keep Threads juggling like a show artist on a television set - my question is will it blow out the OS or cause some corruption in the vm or in some un-anticipated way cause the platform to become unstable.

The same question could apply to Random Access File just like PrintWriter or several other io channels, your profile says you are a main frame so let's envision an OC-256 drop.

Maybe not real busy or something, if sys cannot keep up we just do a pancake or something:

/**
* on Unice, Max File Handles == 60
* on M$ #define FOPEN_MAX 20
*/
final java.lang.Integer MAX_THREADS 
             = 
             new java.lang.Integer(solarisWorkaround?60:20);
final java.lang.Integer MAX_OPEN_FILE_HANDLES 
             = 
             new java.lang.Integer(MAX_THREADS.intValue() - 4);
final java.lang.Integer BUFFER_SIZE 
             =
             new java.lang.Integer(solarisWorkaround?8192:4096);//

That's from my preliminary concepting, let us consider that two or more of the open file handles, which here are conceputalized as Threads ( that is how could get something to run in my prototyping ) .... if two of the File Handles were something from the java.io.* but were new'd on the same java.io.File object, would that develop system instability.

Not code sync() issues, system issues.

[Norm]

Sorry, I don't remember any oc's past about 15. I got out of it about 1987. I don't even remember what oc stands for. I used to look them up on a green card/white card/yellow book.
I would wonder if having different processes/threads open a file some read, some write could work. It might depend on the OS. Not a clue.

[fishtoprecords]

While a random access file can handle it, I don't like doing this. Do you really need a single instance of the file? or can you use the more standard approach, which is to open the file for read, open a new file as a temp file (perhaps even in /tmp) which you write to. At the end of the process, you close the read file, rename the temp file to the old name, and close everything.

This makes it so only one output file is in existance.

I would not allow multiple threads to write, rather I'd use a queue to have all the reader threads put write commands to a single thread that does the work.

If the server could use something like NFS for the file store, its not reliable to have multiple machines writing to a single file.

[Nicholas Jordan]

While a random access file can handle it, I don't like doing this. Do you really need a single instance of the file?

That is the core question, I do not really need it, while coding yesterday I came up with:

    public TemporaryOrderForm()
    {
        this.SessionMap = new java.util.TreeMap<Integer,OrderFormRequestObject>();//
    }
    public void init(javax.servlet.ServletConfig config) throws javax.servlet.ServletException
    {
        try
        {
            init();
            return;
        }
        catch(javax.servlet.ServletException SERVLET_EXCEPTION)
        {
            throw SERVLET_EXCEPTION;
        }
    }
    // Kitty Litter.
    public void init() throws javax.servlet.ServletException
    {
        try
        {
            // Logfile.
            java.io.File LogFileObject = new java.io.File(logfileName);
            if(LogFileObject.exists())
            {
                logFile = new java.io.FileWriter(LogFileObject,true);
                logWriter = new java.io.BufferedWriter(logFile);
            }
            else
            {
                logFile = new java.io.FileWriter(LogFileObject);
                logWriter = new java.io.BufferedWriter(logFile);
            }

            // Actions file.
            java.io.File ActionsFileObject = new java.io.File(actionsName);
            if(ActionsFileObject.exists())
            {
                actionsFile = new java.io.FileWriter(ActionsFileObject,true);
                actionsWriter = new java.io.BufferedWriter(actionsFile);
            }
            else
            {
                actionsFile = new java.io.FileWriter(ActionsFileObject);
                actionsWriter = new java.io.BufferedWriter(actionsFile);
            }
            // Belvedere file: reserved for unanticipated use.
            java.io.File BelvedereFileObject = new java.io.File(belvedereName);
            if(BelvedereFileObject.exists())
            {
                belvedereFile = new java.io.FileWriter(BelvedereFileObject,true);
                belvedereWriter = new java.io.BufferedWriter(belvedereFile);
            }
            else
            {
                belvedereFile = new java.io.FileWriter(BelvedereFileObject);
                belvedereWriter = new java.io.BufferedWriter(belvedereFile);
            }
            return;
        }

That still leaves several knotty sync() issues, doing the round-robin may need a few additional file(s) to allow retirement of buffer issues but it would not be at all difficult for me to go to an array of five or six file handles and let Actions File settle down before retrieving. This approach could be put on a Timer and let the timer run for an hour or a day or something before doing a synchronized pointer rotation. I do not have the nomenclature in my forebrain, it is a standard approch to such things as tip of day and is discussed in my Algorithms in Java by Sedgewick ~ a useful text in that it is just a little ahead of me but well within reach and dispenses with the sophmorics.

or can you use the more standard approach, which is to open the file for read, open a new file as a temp file (perhaps even in /tmp) which you write to. At the end of the process, you close the read file, rename the temp file to the old name, and close everything.

Given your experiences with such things, given a Tier-1 rack that has a one-second turnaround for file-upload and tab over to browser then hit refresh, would we be on safe ground to round-robin once a day or something - leaving one of three for 'active file' one for 'settle-flush' and one for 'retrieval'?

This makes it so only one output file is in existance.

Line continuation char in source here for posting clarity only, not in development prototyping sources.

//
public void doPost(javax.servlet.http.HttpServletRequest request,...
{
  response.setContentType("text/html");
  java.io.PrintWriter out = response.getWriter();
  //
  synchronized(this)
  {
    String headerName = null;
    String headerValue = null;
    java.util.Enumeration HeaderEnumeration = request.getHeaderNames();
    if(HeaderEnumeration.hasMoreElements())
    {
       do
       {
          headerName = (String)HeaderEnumeration.nextElement();
          headerValue = request.getHeader(headerName);
          logWriter.write(headerValue,0,headerValue.length());
          logWriter.write(UNIT_SEPARATOR.toString(),\
                 0,UNIT_SEPARATOR.toString().length());
       }
       while(HeaderEnumeration.hasMoreElements());
       logWriter.write(RECORD_SEPARATOR.toString(),\
                 0,RECORD_SEPARATOR.toString().length());// end of record
       logWriter.newLine();
       logWriter.flush();
       }
    }
    javax.servlet.http.HttpSession SESSION = request.getSession(true);
    String ServerSessionValue = SESSION.getId();//
    //.....

I would not allow multiple threads to write, rather I'd use a queue to have all the reader threads put write commands to a single thread that does the work.

Basically, two threads doing file-writes on one system file handle is just too dicey without dedicated hardware and real system engineering. Okay, listen to voice of experienced reason from years of field experience watching others in the position I am in here.

If the server could use something like NFS for the file store, its not reliable to have multiple machines writing to a single file.

Okay, clear answer is that this is just too much to ask. KISS rules here.

Norm, that 256 was something I dug up recently while doing research on ..... is that an array in the background of your avatar? If so, why is a sky tracker backdrop for a optical nav tool being ( humor folks, humor ) used as a prop for your movie-carrer photo?

[Norm]

FYI The array in the background is a solar panel that helped keep my beer cold.

[fishtoprecords]

FYI The array in the background is a solar panel that helped keep my beer cold.

And you are holding (and using?) a sextant? To make sure you house hasn't moved over night?

[Nicholas Jordan]

FYI The array in the background is a solar panel that helped keep my beer cold.

( humor folks, humor )

Your profile says you are an engineer, okay so my idea the structure was to gather Compton showers at the South Pole was based on the idea of having shirt off in a warm 35 degree day for a standard photo for folks back home used a sextant to insure the South Pole was not moving. Sort of tells you where my mind is at.

Have you considered homebrew? The rich flavor and robust presence is much better than commercial beer.

[Norm]

Picture shows me trying to find out where I am somewhere in the South Pacific pre GPS.
A sailboat is too bouncy for beer making.

I'll have to check to see what's happened to my profile. I'm not and never was an engineer.

[Nicholas Jordan]

I'll have to check to see what's happened to my profile. I'm not and never was an engineer.

My remark was on the basis of "Retired IBM mainframe programmer" ~ I used the term engineer to convey ( here ) one who thinks that way, an informal useage.

Picture shows me trying to find out where I am somewhere in the South Pacific pre GPS.

Okay, but there is something in the background that makes it look like thats a 1950's avionics radar to me.

A sailboat is too bouncy for beer making.

Good, you know something about beer making.

[Norm]

I think of engineers as bridge builders or train drivers. I've always been a tool builder, when I didn't have to do my assigned job.

Background is a solar panel

Well sort of. I made several batches while I was in NZ and Singapore. But that was from kits not from scratch. Haven't tried it here yet.