Page History

...

• Miscellaneous
  • OFBiz's Data File Tools Some tips from Jacopo
  • How to use EntityWhereString A tip from GrimTim
  • How to troubleshoot SQL errors A tip from Chris Lombardi
  • Tips for View Entities A tip from SkipDever
  • How to connect to an External Database A tip from Adrian Crum
  • How to save customised data for import as demo data A tip from Raj Saini
  • Is it possible to delete products, categories, catalogs, etc., that are no longer needed?
  • About lastUpdatedStamp, lastUpdatedTxStamp (transaction), createdStamp, and createdTxStamp

• MySQL
  • MySQL Issues

• Oracle
  • Some tips from Jacopo

...

For production, remember that the truststore of the "client" would hold the public key exported from the keystore of the "server". Conversely the truststore of the "server" would hold the public key exported from the keystore of the "client". Making the keystore and truststore identical on both sides makes life a bit easier for testing, but make sure you toughen things up before you go into production!!!

Thanks to Andrew Sykes

About lastUpdatedStamp, lastUpdatedTxStamp (transaction), createdStamp, and createdTxStamp

They are the timestamps that the entity engine automatically maintains for all entities, unless you use no-auto-stamp=true in the entity definition. But by default all entities will have these four fields.

The transaction stamps are when the transaction was begun that the change is part of, and the stamps are within that transaction, although they are an absolute value. But to order the actual records that changed within the transaction. The entity engine does do things for these stamp fields when it maintains them, by the way, that ensure that within a transaction each updated or created stamp, depending on whether it's a create or updated, is unique for that transaction.

So it'll keep track of the last one and always increment it by one, even if it's been less than a millisecond since the other record went through. As long as you don't have more than a thousand records going into the database per second in a single transaction then you shouldn't have problems with overflowing it too much.

But it is important that those are unique, so we can order all the records by these stamps and basically reproduce the transaction to send it over to the other server. Even reproducing the transaction we can't always eliminate problems with foreign keys. Anyway that's the intention here, to reduce problems with foreign keys as much as possible and recreate the data changes on the remote server when the synchronization goes through

Adapted from Advanced Framework Transcription PDF