Robust messaging between Oracle RAC and Oracle XE

Question

We ran into Bug 13484963 (ORA-3146 from AQ propogation from 11.2.0.3 to 11.2.0.2) - which means that a 11.2.0.3 queue fails to propagate to a 11.2.0.2 queue, due to this bug (ORA-03146: Invalid buffer length for TTC field).
I described the error in posting Bug 13484963: 11.2.0.3 AQ to  11.2.0.2 in the AQ forum, but no responses.
My question to this forum is what alternatives are there are to AQ, for passing XML/CLOBs robustly between a 11.2.0.3 platform and a 11.2.0.2 platform, when the network is at times not robust.
For example, rolling a custom PL/SQL solution will need to use a db link to push data across. If that tcp connection breaks without sender or receiver getting a FIN/RST bit set in a packet, the party will not know the tcp connection broke. And will wait. Forever. Until terminated externally (e.g. alter system disconnect session). There is no tcp timeout. There is no TcpKeepAlive option supported with such a db link connection. This requires more custom processing for monitoring existing custom processes (b-brain monitoring a-brain issue). Gets ugly.
With AQ for example, this is not a problem as it handles the same issue without a problem (likely internal code timeouts set via signal/event handlers?).
Any suggestions as how one can address the basic requirement for pushing XMLs (as CLOBs) with minimal hacking between databases without AQ?

Answer 1

We have a "solution" that requires a data push from 11.2.0.3 to XE in this our case the size of data to be sent is fairly small (20-30 rows) and the target system does not require updates on every row change, data is pushed every 15 seconds across a database link using as merge statement executed in a pl/sql package run by a scheduler job. To mitigate for delays and network issues the job is monitored and shot in the head if it takes longer than 10 seconds, as you are dealing with clobs I'm not sure if this will work as
Another alternative we have looked at is Continuous Query Notification, this only got as far as a proof of concept as the customer changed their mind in our case the requirement was to push a small subset of the rows inserted into a table into a remote database to enable our monitoring team to check for certain types of activity the solution was a java process that registered a query on the source database and when notified of a change grabbed the rows and inserted them into the target, as we where looking at only a small set of rows (80-300 rows per day out of 1.5-2 million inserts) and the target application was written in java this proved workable.
Neither solution is elegant, particularly scalable or lacking in PL/SQL Hacks and in our case both are workarounds to an inflexible core application and new requirements that do not generate large revenue, currently we are looking at upgrading the XE databases to SEONE so that we can get support, patches and upgrades and move over to AQ for these type of problems.