Conflicts resolution methods in Oracle Lite

Question

Can anyone please provide the answers of the following questions?
1_What Methods are used for Conflict detection and resolution for concurrent updates by multiple clients in Oracle lite databases?
2_ Is there any method that extract semantic relation from the concurrent update transactions and create a global update schedule?
3_ Does oracle lite use conflict avoidance mechanism?
4_ What replication method is used by Oracle Lite Database?

Answer 1

In terms of conflict resolution with oracle lite, which end do you mean? conflict resolution in the client database (ie: oracle lite) or on the server side when processing client uploads (this is just a standard oracle database), also not sure what you are trying to achieve
*1_What Methods are used for Conflict detection and resolution for concurrent updates by multiple clients in Oracle lite databases?*
I assume in the following that you are talking about dealing with uploads
Depending on how the publication items are defined, the process is quite different.
a) fast refresh publication items
When the client synchronises, the upload data is uploaded as a packed binary file which is then unpacked and inserted into in queue tables in the mobileadmin repsitory (table names begin CFM$ followed by the publication item name). This is the only action that happens during the actual sync process.
A second and independent process, not linked to the actual synchronisation - the MGP process, runs on the mobile server, and this has three phases - apply, process logs and compose that run one after the other. You can set the MGP to only do the apply phase, or all three.
during the apply phase the data in the in queue tables for a particular user/transaction will be applied to the server database. Normally the MGP process is set to have three threads (this can be changed, but three is the default), and therefore three client uploads will be processed in parallel, but each of these threads is independant of the others and therefore should be seen as seperate transactions.
It should be noted that even if you have 50 or 100 users synchronising concurrently, only three upload sets will be processed at any one time, and almost certainly a period of time after the synchronisation has completed (may be many hours depending on the MGP cycle time)
As each of the apply threads is a seperate transaction, there is no concept of concurrency built in, and the only conflict resolution by default is based on the server wins/client wins setting of the publication item. where multiple users are updating the the same server record with 'client wins', the first user will update the data, and then the next user will update the data (just a repeat of the previous one). NOTE also that in the case of an update, ALL columns in the record are updated, there is no column level update.
There are customisation options available to provide finer grained control over the apply process, look at the PLSQL callback packages registered against each publication item for beforeapply, afterapply, beforetranapply and aftertranapply, Apply DML procedures against the publication items and also the CUSTOMIZE package at the MGP level
b) complete refresh publication items
where the publication as a whole has a mixture of fast and complete refresh publication items, these normally work in the same way as the fast refresh described above. Where however you just have complete refresh items the data MAY be written directly to the server table on upload
c) queue based publication items
These work in realtime, rather than with a delay for the MGP process to pick up the data.
When the user synchronises, the uploaded data is is written to the in queue tables in the same way, but when this is completed, a package (defined as part of the publication definition) is called, and the procedure upload_complete is run passing in the user and transaction identifiers. This package needs to be hand crafted, but you have full control over what and how all of the uploaded data is processed, but again this is a single transaction for that user. If you want to look at other sessions running, you need to find a way to implement this.
*2_ Is there any method that extract semantic relation from the concurrent update transactions and create a global update schedule?*
As noted above, the uploads may be processed in parallel, but they are seperate transactions, so no built ins
*3_ Does oracle lite use conflict avoidance mechanism?*
Only the basic oracle stuff, unless you use the customisation options to write your own
*4_ What replication method is used by Oracle Lite Database?*
The different types of publication items select data from the server database for download in different ways
a) fast refresh
change logging tables and triggers are created in the server database. These are scanned during the MGP process logs phase to determine what changes have happened since the last MGP compose, and what publication items they affect. The MGP compose then runs and this uses the same three threads to process the users in alphabetical order using the change keys to populate data in out queue tables (prefixed CMP$) in the repository. These have the PK values for the data, plus a transaction types (insert/update/delete). All the MGP process does is populate these out queue tables.
When the user synchronises, the data in the out queue tables is used as a key list to extract the data from the actual server tables into a packed binary file, and this is sent to the client.
b) complete refresh
there is no pre-preparation in this case, the data is streamed directly from the server database into the packed binary download file
c) queue based items
in real time when the user is synchronising after the apply has been done by the uploade_complete procedure, a second procedure download_init is called. Within this you have to code the data extract, and MUST populate tables (you also need to create them) CTM$<publication item name> these are effectively out queue tables, but contain all of the data, not just the PK values. At the end of the procedure, the data is streamed from these into the binary file for download.
Depending on the definition of your apublication, you could have one or more of the above types (VERY bad idea to mix queue based and fast refresh unless you are very sure about what you are doing) and therefore there may be a mix of different actions happening at different times
In conclusion i would say that try and send seperate data to clients so that they do not interfere with each other, and for inserts use uniqueue keys or sequences. If you MUST send the same data to different clients for update, then the queue based approach provides the best control, but as it is real time is not as scalable for large data sets.