|Subject||Re: [IBO] Syncronizing transactions|
> Most applications will have multiple transactions, and certainlyDML caching is a good and comfortable method for syncronizing,
> different apps don't share the same transactions. A transaction
> only "sees" information that has been updated or added that is
> attached to it's own transaction. When something is changed in
> another app or transaction, what is the best way of updating that
> info to other apps or transactions?
> I use a transaction refresh to update, but it seems illogical to have
> to have a user continually press a refresh button. I have also played
> around with IB_Event to notify the app of changes to key records.
> How does everyone else deal with this? Is there some generic
> procedures that can be used?
but there are several nuances:
1) Update notifications are fired on table posts but before update
transaction completion. This can produce some problems with
long time transactions performing more then one update.
2) Table used to register DML events grows up with no limit.
3) There are 2 additional operations accompanying every update:
a) INSERT into DML event registering table on server
b) SELECT from DML event registering table on client
The way I'm using to syncronize several clients is following.
After update transaction completes, client performing update
sends notification over TCP/IP to all other interested clients.
Notifocation contains information about update type
(INSERT, DELETE, UPDATE), updated table identifier and
key information (NOTIFY_KEY_INFO).
Clients interested to reflect updates perform something
like this when update notification hase been received:
on INSERTs & DELETEs