New in LiveCycle ES2 – GDS in the Database

In the ES2 release, it is possible to configure the Global Document Storage (GDS) to be persisted in the database rather than on a server or network-shared (for clusters) filesystem. Although there is a performance penalty, this option is worthy of serious consideration given the fact that backup and restore procedures will become much simpler. The database tables start with the following prefix – tb_dm_.

If the GDS is persisted on a filesystem, backups of the filesystem as well as the database would have to be time-synchronized which is problematic in large organizations.

However, if you use document-type process variables in your orchestrations (short or long-lived), make sure that the ‘Default document max inline size‘ is set high enough to include most or all of your documents. Otherwise, invoking a short-lived orchestration 1000 times with a 10 MB input document will cause your DB to grow by 10 GB (especially the tb_dm_chunk table). It will continue to use 10 GB until these documents are cleaned up.

For more on process variables of the type com.adobe.idp.Document, please see Adobe Technote here.

The cleanup happens based on the setting ‘Default document disposal timeout‘. You can configure these in the LiveCycle Admin Console (navigate to Settings->Core System->Core Configurations). A record in the tb_dm_chunk table will be deleted when it has no associated records in the tb_dm_session_reference table referring to its DOCUMENTID.

You can safely set ‘Default document max inline size’ to 5 MB (5242880 bytes) or 10 MB (10485760 bytes).

You get to choose your GDS option while running the LiveCycle Configuration Manager (LCM) following the install.

Please note that for LiveCycle Content Services ES, there is no option to persist the Content Storage Root in the database. It still has to be backed up time-synchronized with a DB backup.

Also note that you still need to define a folder for the GDS since it is still needed for persisting things like Workbench ‘Record and Playback’ sessions etc. In a horizontal cluster, this needs to be a single network share which can be read from and written to by all of the cluster members. If you needed to change the location of the GDS after the installation, please follow instructions posted by Adobe’s Bart Vossen in the ‘Dr Flex & Dr LiveCycle’ blog.

This entry was posted in Adobe LiveCycle ES and tagged . Bookmark the permalink.

2 Responses to New in LiveCycle ES2 – GDS in the Database

  1. Rob McDougall says:

    Hi Jayan,Is there any way you can quantify the performance penalty of placing the GDS in the database? I realize that it might vary a lot however it’s difficult to know whether to make the tradeoff without knowing what the performance penalty might be.Some data (however qualified) would be helpful.Regards,Rob

  2. Jayan Kandathil says:

    That’s a hard one. According to Engineering, it’d depend on factors such as these:- your document service and application, and how sensitive it is to GDS performance- whether the GDS objects are long-lived (therefore in the DB), or short-lived (therefore still in the filesystem)- your DB server and how well-tuned it is for handling LOB data (GDS document objects are BLOBs in the DB)- the size of the GDS objects