Aye! Aye! Aye! If you want all files updated, then use transaction journaling and syncing. There are way more issues doing it like you are than you guys probably realize.
However, if you must use triggers, then make an interface to OpenMQ and use that - you avoid all the writes, the sleeping and waking, read/write ordering issues, network error handling issues, transaction failure issues, and so on. I seriously recommend that you reconsider your solution here, it really is a very precarious solution that is basically going to work fine until one of the situations you are trying to protect against happens, in which case both copies will be in an unknown state. Jim > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of David McGehee > Sent: Friday, July 30, 2010 2:56 PM > To: [email protected] > Subject: RE: Trying to avoid trigger recursion in a jBASE system > > We use triggers to keep our co-location in sync on a hot basis. We have a > somewhat more Complex situation in that ALL of our jbase files are kept in > sync this way. To manage this, And in order to preclude recursion, our > common trigger creates a key describing the file, record Key, and operation > (write, clear, delete) and writes the record with that key into a common file > at The incurring site. A separate process is WAKED and writes the available > records to the corresponding File at the other site. There a process which > was started at port 4999 writes the transported record(s) to the target File. > The trigger code is written such that it checks the process port and if > 4500, > ignores the trigger trip and exits. > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of LWhite > Sent: Friday, July 30, 2010 9:55 AM > To: jBASE > Subject: Trying to avoid trigger recursion in a jBASE system > > Hello, > > We will be implementing a new file structure. Due to time constraints the > decision was made to set up parallel files and then make code changes as we > can make human procedural changes. The files need to be kept in sync and > the first idea was to use post write triggers. I am concerned about recursion > and was hoping someone here could shed some light on the issue. > > So let me offer an example. > OLD.PRODUCT.FILE > NEW.PRODUCT.FILE > > Attributes will not be in the same location. Therefore, attribute 2 through 10 > on the old file will be scattered from 11 to 80 in the new one. > > Every time one of the shared attributes in OLD.PRODUCT.FILE is changed the > matching attribute in NEW.PRODUCT.FILE needs to be updated. The same > thing needs to happen from NEW.PRODUCT.FILE to OLD.PRODUCT.FILE. > > Can we write the trigger to ignore file changes made by the other trigger? If > so, how? > > Is there a better way to do this that will keep nearly real time synchronization > at a lower system over head cost? > > The only system information that I thought was important to this question > was: > RELEASE Information : Major 3.4 , Minor 10 , Patch 0373 > > Thank you > > -- > Please read the posting guidelines at: > http://groups.google.com/group/jBASE/web/Posting%20Guidelines > > IMPORTANT: Type T24: at the start of the subject line for questions specific > to Globus/T24 > > To post, send email to [email protected] To unsubscribe, send email > to [email protected] > For more options, visit this group at > http://groups.google.com/group/jBASE?hl=en > > -- > Please read the posting guidelines at: > http://groups.google.com/group/jBASE/web/Posting%20Guidelines > > IMPORTANT: Type T24: at the start of the subject line for questions specific > to Globus/T24 > > To post, send email to [email protected] To unsubscribe, send email > to [email protected] > For more options, visit this group at > http://groups.google.com/group/jBASE?hl=en -- Please read the posting guidelines at: http://groups.google.com/group/jBASE/web/Posting%20Guidelines IMPORTANT: Type T24: at the start of the subject line for questions specific to Globus/T24 To post, send email to [email protected] To unsubscribe, send email to [email protected] For more options, visit this group at http://groups.google.com/group/jBASE?hl=en
