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
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.