MimePublishPlugin[ReplManagerPlugin][1.0]=\
org.xmlBlaster.contrib.replication.impl.ReplManagerPlugin          
          

Normally a check is made for messages to be sent to the slave. If such messages are outdated or if the replication key identifying such messages is not monoton incresing it is normally considered an error and messages are not dispatched. For Multimaster approaches this is not true since the replication keys can come from several Masters. For such cases you can disable the check by passing true here. This will mean that messages which are believed to be wrong under a single master perspective are sent anyway.

Used to map columns. This is a prefix, not a complete name. You can define several such mapping entries, one for each column you have to map. The syntax for the name of such properties is the prefix replication.mapper.column. added with ${schema}.${table}.${column}. As value you specify the name to be used for that column on the Writer side: only the bare column name without any schema or table name. Used on the Slave. Has only effect if you use the DefautMapper.

Used to map schemas. This is a prefix, not a complete name. You can define several such mapping entries, one for each column you have to map. The syntax for the name of such properties is the prefix replication.mapper.schema. added with ${schema}. As value you specify the name to be used for that schema on the Writer side.Used on the Slave. Has only effect if you use the DefautMapper.

Used to map tables. This is a prefix, not a complete name. You can define several such mapping entries, one for each table you have to map. The syntax for the name of such properties is the prefix replication.mapper.table. added with ${schema}.${table}. As value you specify the name to be used for that table on the Writer side: only the bare table name without any schema name. Used on the Slave. Has only effect if you use the DefautMapper.

The maximum number of rows (entries) to be sent in one single message when a CREATE operation has been detected. This has only effect if replication.sendInitialTableContent has been set to true. By tables containing much entries this would mean that the initial content can be split among several messages, each of which is executed on the Slave as a single transaction. This means that if a failure occurs, the initial update has to be repeated. Used on the Master.

The poller interval for updating the data exposed to the JMX Monitor in ms. Note that this is not the refresh rate of the monitor itself. The refresh rate is specified in the customize.xsl file as the property refresh.rate. The property statusPollerInterval controls a background thread which updates the data exposed. This approach has been choosen because there are properties which synchronize objects when invoking their getter method. This would result in the monitor being blocked while shuch operations are ongoing and in some case it could result in lock up. Worth to know is that there is only one single thread for all slaves keeping this way resource consumption low even when choosing lower values for this property. This is a property which has to be defined on the ReplManagerPlugin.

Used only on oracle. On initial updates, before importing the data the Functions of this schema will be deleted if true.

Used only on oracle. On initial updates, before cleaning up all resources belonging to the schema to wipe out an exception will be thrown if you specify true and there still are users logged in to that schema. If you specify false only a warning will be logged.

Used only on oracle. On initial updates, before importing the data the Indexes of this schema will be deleted if true.

Used only on oracle. On initial updates, before importing the data the Packages of this schema will be deleted if true.

Used only on oracle. On initial updates, before importing the data the Procedures of this schema will be deleted if true.

Used only on oracle. On initial updates, before importing the data the Sequences of this schema will be deleted if true.

Used only on oracle. On initial updates, before importing the data the Synonyms of this schema will be deleted if true.

Used only on oracle. On initial updates, before importing the data the Tables of this schema will be deleted if true.

Used only on oracle. On initial updates, before importing the data the Triggers of this schema will be deleted if true.

Used only on oracle. On initial updates, before importing the data the Views of this schema will be deleted if true.

Used to overwrite the default search mechanism used on the slave when updating or deleting entries. If nothing is specified here, when an update or a delete operation is replicated, the entry to update or delete is searched in the destination database. If the table has primary keys defined, these primary keys are the only columns used for the search. If the table has no primary keys, all searchable columns are used in a SELECT .. WHERE ... AND statement. This can be timeconsuming and it does not allow the user to change such columns on the destinations. Here you can define which columns have to be used to search. An example: replication.searchable.XMLBLASTER.TABLE1=COL1,COL2 would update the entry which meets the SELECT XMLBLASTER.TABLE1 WHERE COL1='aaa' AND COL2='bbb' statement (here aaa and bbb are the values to be searched). In the example XMLBLASTER is the schema and TABLE1 is the table name. If such a configuration is specified for a given table, then it is used even if the table has primary keys defined, however a warning is output on its first usage. If you specify a column which is not searchable, a warning is written and the inherent column is not used for the search. If you specify a column which does not exist, a warning is output but the entry is still considered in case the column is added later. The key of the property has the syntax replication.searchable.${schema}.${table} and the value is a comma separated list of column names used for the search.

The syntax for the key is table.${catalogName}.${schemaName}.${tableName} where the catalog and the schema are optional while the table name is mandatory. The syntax of the values is actions=${actions},trigger=${triggerName},sequence=${seq} where all arguments are optional. The ${actions} can be a combination of the three characters IDU where I stands for Insert, D for Delete and U for update. These are the actions which have to be replicated. The ${triggerName} is an optional name for the trigger to be added, if you don't specify anything the application will try to assign a valid name for it. Be aware that the length of the trigger name may be limited. Consult the documentation of your DB for this. The ${seq} is an integer telling at which sequence this table will be replicated on initial updates. Low numbers will come first. All tables which have no specified sequence will come in a random sequence (a simple check is made against foreign keys to avoid incosistencies) after the tables for which a sequence number has been explicitly assigned.

   java -Dwipeout.schema=XMLBLASTER org.xmlBlaster.contrib.replication.impl.SpecificDefault