Blocking sessions during MGP compose

Question

We keep getting the MGP compose process blocked by inactive sessions
We raised a SR with Oracle and they suggested adding the instance parameter DO_APPLY_BFR_COMPOSE=YES to webtogo.ora, but this does not seem to have cured the problem.
From tracing, it seems that the problem is an inactive apply session that resulted in an error, being there for the user it is trying to compose. The actual block is on the table MOBILEADMIN.C$ALL_CLIENT_ITEMS.
If an apply fails due to an error (eg: constraint violarion, trigger failure etc), it executes the statement
UPDATE MOBILEADMIN.C$ALL_CLIENT_ITEMS SET CRR='Y' WHERE CLIENTID=? AND PUBLICATION_ITEM IN ( SELECT PUBLICATION FROM MOBILEADMIN.C$ALL_TEMPLATE_ITEMS ati WHERE ati.TEMPLATE=?):
as part of the copy to the error queue. It also looks to execute the same statement at the beginning of the compose for the user, hence the block.
The other odd thing is that looking at the blocks this morning, the MGP apply/compose kicked off at 7.09 am. The user synchronised at just after 8 am, by which time the MGP cycle was well into the compose phase, and there is no record of apply activity for the user within the cycle (the actual apply is in the following cycle), the the content of the blocking session was definitely apply code.
MGP used to do all of the applys first, and then all of the composes, with a test to skip the compose if there was data in the user in queue. The upgrade to 10.2 (or one of the many patches since) looks to have changed the default behaviour to attempt an apply before each user compose, but the parameter above was supposed to set the server back to its old behaviour (ie: keep apply and compose seperate). NOTE i have not seen any of the old 'compose deferred because of unprocessed data in the in queue' messages in the compose recently either.
Upshot is that it looks like it is still mixing apply and compose together, and where the apply hits an error, the apply thread is not closing correctly, or releasing its locks.
Does anyone have any information about the parameters
DO_APPLY_BFR_COMPOSE or
SKIP_INQ_CHK_BFR_COMPOSE (this appeared with a value of NO when we added the other parameter.
Information from oracle is that the two are mutualy exclusive (?) but they are not documented anywhere that i can find (the one reference on metalink leads to a non existant note), and oracle seem reluctant to supply any
so PLEASE
a) any information about the parameters
b) any dependancies (ie: parameters not working because we are missing a patch)
c) location of documentation
d) any other ideas

Answer 1

which version are you on?
we are on 10.2.0.2, so unsure if this works in other versions
The standard mobile manager parameters screen does not by default show these settings, but we were asked to add them into the webtogo.ora file in the [CONSOLIDATOR] section eg:
[CONSOLIDATOR]
# Installer will change these values
SERVER_VERSION=8.1.7
SKIP_INQ_CHK_BFR_COMPOSE=YES
DO_APPLY_BFR_COMPOSE=NO
RESUME_FILE_SIZE=512
# 8.1.7
# Installer won't change these values
MAX_THREADS=3
JDBC_DRIVER=oracle.jdbc.driver.OracleDriver
once this was done we stopped and restarted the mobile server and then the new parameters will appear in the normal data synchronisation>administration>instance parameters screen
our current setting on the live system are
SKIP_INQ_CHK_BFR_COMPOSE YES
DO_APPLY_BFR_COMPOSE NO
and this does the compose whether or not there is pending data in the in queues for the client. Just my opinion, but there seems little point in doing the check as even if you force two tries of the apply process (one in the main apply phhase before the compose phase, and one just before composing for a particular user), the data in the second apply will not be picked up on fast refresh publication items as the 'snapshot' of the changes has already been done in the process logs phase