Clustering Support for "On Demand" Read

"On Demand" Read, as read only

The default behavior of "on demand" read is that filebc just read the content of the file and sent the response back to the corresponding component which made the original read request, Note: this is only a read only operation so any number of thread can be reading/accessing the same file , i.e filebc can serve any number of request without worrying about synchronizing access to the file , similarly if filebc is in cluster , i.e more than one instance of filebc may be accessing the same the file without any synchronization.

"On Demand" read with delete

In this option the file is deleted once the file is read, So in this case the access to the file needs to be synchronised both within and accross the process. i.e within the process the filebc ensures that only one thread can have access to the file during the reading of the content, and across the process only one process can access the file at any given point of time

a) Archive option

This is the default option while using the delete option, In this case the file is archived either in a default location or in the archive directory based on the user configuration, with this option user can keep a history of the all the file that has been processed , usually during archiving the filename is appended with a uuid to keep the name unique within the given directory

b) Without Archive

User can choose not the archive the prcessed file , in this case the file is simply deleted once the filebc has completed the read

Note: Filelocks (java.nio.channels.FileLock) are used to synchronize access across nodes in the cluster

Platform dependencies
 
This file-locking API is intended to map directly to the native locking facility of the underlying operating system. Thus the locks held on a file should be visible
 to all programs that have access to the file, regardless of the language in which those programs are written. 

Whether or not a lock actually prevents another program from accessing the content of the locked region is system-dependent and therefore unspecified. 
The native file-locking facilities of some systems are merely advisory, meaning that programs must cooperatively observe a known locking protocol in order to 
guarantee data integrity. On other systems native file locks are mandatory, meaning that if one program locks a region of a file then other programs are actually
 prevented from accessing that region in a way that would violate the lock. On yet other systems, whether native file locks are advisory or mandatory is
 configurable on a per-file basis. To ensure consistent and correct behavior across platforms, it is strongly recommended that the locks provided by this API be
 used as if they were advisory locks. 

This page (revision-8) was last changed on 31-Mar-09 15:07 PM, -0700 by sujit.
This page was created on 31-Mar-09 13:41 PM, -0700 by sujit.

More info...