Professional Documents
Culture Documents
Tafj Cache
Tafj Cache
R20
TAFJ C a c h e
Amendment History:
Revisio
Date Amended Name Description
n
1 1st June 2016 R. Vincent Initial version
2 11th July 2016 R. Vincent Add JBoss Data Grid
3 23rd July 2016 R. Vincent Add WAS Extreme Scale
7 24th April 2017 R. Vincent Change instructions for Ignite starting node
8 25th Sep. 2017 R. Vincent Add JBoss specific instructions for Write through
9 29th Jan. 2018 R. Vincent Add new JBC keywords for caching
13 14th Mar 2020 Riswana Update Ignite Jar versions for download
Page 2
TAFJ C a c h e
Copyri g h t
Copyright © Temenos Headquarters SA 2009-2020
All rights reserved.
This document contains proprietary information that is protected by copyright. No part of this document may
be reproduced, transmitted, or made available directly or indirectly to a third party without the express
written agreement of TEMENOS UK Limited. Receipt of this material directly TEMENOS UK Limited
constitutes its express permission to copy. Permission to use or copy this document expressly excludes
modifying it for any purpose, or using it to create a derivative therefrom.
Temenos Headquarters SA
2 Rue de l’Ecole-de-Chimie,
CH - 1205 Geneva,
Switzerland
Please include your name, company, address, and telephone and fax numbers, and email
address if applicable. TAFJdev@temenos.com
Page 3
TAFJ C a c h e
Table of Contents
Copyright................................................................................................................................................ 3
Errata and Comments............................................................................................................................ 3
T24 Overall Infrastructure....................................................................................................................... 6
Prerequisites........................................................................................................................................... 6
Benefits of TAFJ Caching....................................................................................................................... 6
Setting up TAFJ Caching........................................................................................................................ 7
Common Setup..................................................................................................................... 7
Caching Dependencies...................................................................................................... 7
Caching Keystore.............................................................................................................. 7
Caching Properties............................................................................................................ 8
Reading Properties from a Database................................................................................ 9
Reading Properties from a File.......................................................................................... 9
Local Caching Setup............................................................................................................. 9
Example of setting up your own cache............................................................................ 10
JBoss Specific Property Setup............................................................................................ 10
Websphere Specific Property Setup................................................................................... 10
Cache Logging TAFJ........................................................................................................... 11
JBC Cache Keywords and Examples................................................................................................... 11
Example:............................................................................................................................. 11
Batch Caching...................................................................................................................................... 12
Apache Ignite Setup............................................................................................................................. 13
Table Setup......................................................................................................................... 13
Ignite Configuration File...................................................................................................... 14
Required Ignite jars.......................................................................................................... 14
Ignite Security...................................................................................................................... 17
Ignite Logging.................................................................................................................. 20
JBOSS Specific Things to Do For Write Through Caching............................................. 20
Oracle Weblogic Coherence Setup...................................................................................................... 21
Oracle Coherence Setup for Clients.................................................................................... 22
Standalone Clients........................................................................................................... 22
All Clients......................................................................................................................... 23
Logging Coherence............................................................................................................. 24
Deploying the TAFJ.gar file................................................................................................. 24
Page 4
TAFJ C a c h e
Page 5
TAFJ C a c h e
This step by step process will tell you how to setup caching for TAFJ.
Prer e q u i s i t e s
This assumes you have installed an external caching solution such as Oracle Coherence.
For Apache Ignite, please refer to the topic Required Ignite Jars and download it. Henceforth,
$COHERENCE_HOME will refer to the Coherence install directory.
Be n e f i t s of TAFJ Cach i n g
The benefits of TAFJ Caching are in execution time which vastly improves. One can see this
in the TAFJ Monitor where cache read time is tracked. As of this writing, TAFJ Caching
caches a set of defined (mostly) read-only tables which are defined in the TAFJ_CACHE
table. After a record is read from the database, the record is cached as a dynamic array (no
matter which cache provider is used). Subsequent reads go to the cache first to check it if it
is there. If it is, this is called a cache hit. If it isn’t, it is called a cache miss.
Page 6
TAFJ C a c h e
The record is removed from the cache before any write occurs so that any subsequent read
will get fresh data from the database. Thus it is better to configure tables which are written
infrequently to avoid cache misses which penalize performance.
Write-through/Write Behind cache might be implemented at a later date, but in this first
phase it is not. The TAFJCaching.jar file supports Apache Ignite 2.0 and up, Oracle
Coherence, Jboss Data Grid, and Webshere ExtremeScale.
Se t t i n g up TAFJ Cac hi n g
Com m o n Set u p
Cach i n g De p e n d e n c i e s
TAFJCaching.jar is only reliant on TAFJLogging.jar, log4j-api.jar, and log4j-core.jar,
TAFJConfiguration.jar, and TemenosSecurity.jar, and the various 3rd party libraries
(depending on which caching mechanism is chosen). TAFJCaching.jar can be used as an
API. Examples are contained in this document.
Cach i n g Keys t o r e
Inside the TAFJCache.jar is a keystore called cachestore.keystore which holds the Ignite
user password, database parameters, and default encryption algorithm. The caching
keystore is loaded from the classpath.
Page 7
TAFJ C a c h e
Cach i n g Prop e r t i e s
Pro p e r t i e s sp e c i f i c to TAFJ
In your TAFJ properties file, set the following property to enable external caching:
temn.tafj.runtime.use.external.caching = true
temn.cache.runtime.use.batch.write=true
Batch write caching caches records inside the application (inside JVM only) until either a
TRANSEND/TRANSABORT or the batch size defined is reached, at which point the batch is
flushed to the database (TRANSEND or batch filled), or emptied (TRANSABORT). Batch
write caching is independent of external caching so one not need set
temn.tafj.runtime.use.external.caching to true as well. The amount of records to batch is set
at the thread level. See “Batch Caching” later in this document.
temn.tafj.runtime.use.cache.dict.item=true
Dictionary caching, as of now, is relegated to the TAFJ local caching mechanism (caching
within the JVM only) as the Object is a complex object and not a String. Local caching
provides the fastest access. Dictionaries are rarely, if at all updated. The whole dictionary
cache expires occasionally and is controlled by the temn.cache.dict.expiry.time property
which is in milliseconds. The default is 4 hours. The cache is also cleared if
STANDARD.SELECTION is rebuilt, but this would happen only on one node and is not
cluster wide.
The property below allows you to switch a caching provider. The default is the Temenos
local cache implementation. A list of supported providers appear in this properties file shown
below.
temn.cache.external.caching.provider= com.temenos.tafj.cache.TAFJLocalCacheFactory
# Providers: Temenos (local cache only across one jvm) use =>
com.temenos.tafj.cache.TAFJLocalCacheFactory
Page 8
TAFJ C a c h e
TAFJ properties will override the caching provider property if provided as well in the caching
properties. If using the API, this can also be passed as a CacheParameter which takes
ultimate precedence.
temn.cache.jboss.jdg.host = localhost
temn.cache.jboss.jdg.port = 11322
temn.cache.was.og.host.port = localhost:2809
temn.cache.was.og.grid.name = TemenosGrid
temn.cache.was.og.domain.name = DefaultDomain
temn.cache.use.database.for.props=false
temn.cache.external.caching.provider= com.temenos.tafj.cache.TAFJLocalCacheFactory
Page 9
TAFJ C a c h e
Then you define the caches declaratively in the caching properties. By default, a Tables
cache is set up in the caching properties as shown below (when creating the table
TAFJ_CACHE and inserting the default entries, the cache defined is called “Tables”). This
cache expires entries after 4 hours (14400 seconds) or when the memory exceeds 100
megabytes for the cache. In this case a “least recently used” policy would kick in booting out
entries. A LFU (least frequently used) policy is also supported.
temn.tafj.cache.name.Tables=Tables
temn.tafj.cache.name.Tables.expiryTime.seconds=14400
temn.tafj.cache.name.Tables.memory=100M
temn.tafj.cache.name.Tables.evictionPolicy=LRU
temn.tafj.cache.name.SHORTLIVED = SHORTLIVED
temn.tafj.cache.name.SHORTLIVED.expiryTime.seconds=60
temn.tafj.cache.name.SHORTLIVED.memory=100M
temn.tafj.cache.name.SHORTLIVED.evictionPolicy=LRU
We would then insert a record into the TAFJ_CACHE for this, ie.
Now whenever a row is read from the database, it will be cached locally across one or many
application servers (depending on the TAFJ caching provider used) for 60 seconds or until a
LRU policy evicted it.
JBos s Sp e c i f i c Prop e r t y Se t u p
In the caching.properties file, for Jboss Data Grid you also need to setup the host and port.
temn.cache.external.caching.provider=org.infinispan.jcache.embedded.JCachingProvider
temn.cache.jboss.jdg.host=localhost
Page 10
TAFJ C a c h e
temn.cache.jboss.jdg.port=11322
(The above assumes Jboss Data Grid started with 100 port offset, ie. If you start with
.\clustered.bat -Djboss.socket.binding.port-offset=100, you should see:
on the console)
temn.cache.external.caching.provider=com.ibm.websphere.ObjectGridProvider
temn.cache.was.og.host.port=localhost:2809, myremotehost:2809
temn.cache.was.og.grid.name=Grid
temn.cache.was.og.domain.name=DefaultDomain
log4j.logger.CACHE=INFO, cache
Page 11
TAFJ C a c h e
the VAR is a string, it will be encrypted and stored in the cache if the provider
supports encryption.
jVars can be stored in a remote Ignite cache without any extra setup. T24 developers should
consider using SharedCachePut/SharedCacheGet to replace CachePut/CacheGet where
data is shared between threads. For database records, one can configure full tables to be
cached and there is no need to use any caching functions as simply doing a READ on the
record will cache it if the table is configured in TAFJ_CACHE. (See above Setting up TAFJ
Caching section.)
Exa m p l e :
PROGRAM TEST.CACHE.SHARED
CACHE.NAME="VarCache"
KEYVALUE="KEY1"
SharedValue = SharedCachePut(CACHE.NAME,KEYVALUE,”Value1”)
SharedValue = SharedCachePut(CACHE.NAME,”key2”,”Value2”)
SharedValue = SharedCacheKeyList(CACHE.NAME, "-")
SharedValue = SharedCacheGet(CACHE.NAME,KEYVALUE)
SharedValue = SharedCacheDelete(CACHE.NAME,KEYVALUE)
SharedCacheClear(CACHE.NAME)
Page 12
TAFJ C a c h e
END
NUMRECS = 0
DONE = 0
RESULT=""
LOOP
READNEXT id FROM SharedValue ELSE DONE = 1
UNTIL DONE DO
READ actual FROM fd, id ELSE
CRT "Unable to read id '":id:"' after getting from the shared
cache"
END
CRT actual
NUMRECS = NUMRECS + 1
REPEAT
EXECUTE "DELETE-FILE TEST.CACHE.FREE.DELETE" CAPTURING output
CRT "Finished"
END
Bat c h Cac hi n g
As mentioned previously, batch write caching is independent of external caching. If external
caching is enabled, batch caching will be disabled regardless of how the property
below is setup. This is because it could interfere with write-through caching. To set it batch
caching, first set your property to true.
temn.cache.runtime.use.batch.write=true
temn.tafj.runtime.use.external.caching=false
What this does is 1) creates the file of type XML 2) creates a record in the TAFJ_CACHE
table with RECID= BATCH.WRITE, CACHENAME=WRITECACHE, and
WRITEBATCHROWS=8. WRITEBATCHROWS tells how frequently to flush to the database
once the cache is full PER THREAD. This is very important as you must size how much
memory this will take for all tables batched and how many threads will be running. Without
adequate memory, one could encounter memory violations.
Page 13
TAFJ C a c h e
So in the case above, JBC WRITE statements on the table BATCH.WRITE will cache rows
up to 8. On the 9th WRITE, records would then be flushed to the DB and the internal cache
would be emptied. The records would not yet be committed until a TRANSEND or
TRANSABORT are seen.
One can also set up existing tables by inserting records into the TAFJ_CACHE tables with a
RECID that matches the TAFJ_VOC RECID, a cache name of WRITECACHE, and some
valid integer for BATCH_WRITE.
Initializer for setting the encryption algo (used to encrypt data in the cache)
Waz7G611E%+6291Tqz (This is now stored only in the database in the table
TAFJ_CACHE_KS_INIT and this initializer is mandatory for Ignite)
The default keystore password 3jyh?=%_baT (if using this on the command line on
windows you must escape the % character, ie 3jyh?=%%_baTO
These values should be changed as well as the database parameters for your target
database existing in the keystore. Please see “Manipulating the cachestore.keystore file”
section later in this document.
Tabl e Set u p
Two tables are required. The TAFJ_CACHE_KS_INIT table which holds the default
encryption initializer and should be changed as this encryption algo is used to encrypt the
keystore password in the properties file. Second, the TAFJ_CACHE table. A table is
targeted for caching by putting it in the TAFJ_CACHE table. Reads and writes of T24 tables
that exist in TAFJ_CACHE will be redirected to the cache. If this table doesn’t exist in
TAFJ_CACHE, create it by running the script createtable_tafj_cache.sql in your
$TAFJ_HOME/dbscripts directory for the appropriate database. This script will also insert
some default tables as well so be sure to look and see which tables are included. The
current table structure is as follows:
CACHENAME VARCHAR2(255)
WRITEBATCHROWS VARCHAR2(5)
Page 14
TAFJ C a c h e
Once the TAFJ_CACHE table is created, create the appropriate rows for tables that should
be cached. An example follows:
For new DBImports using the DBImport progam, the TAFJ_CACHE table will be created for
you empty.
temn.cache.ignite.conf.file.loc=<tafj.home>/conf/cache/ignite-cache.xml
For information regarding Ignite caching, please see the Apache Ignite documentation at
https://ignite.apache.org/index.html. Due to security policy, we will not ship the Ignite
jars with TAFJ pack. Hence download the below Ignite jars from the Ignite distribution (note
that version numbers will change with Ignite updates).
ignite-core-2.7.5.jar
ignite-log4j2-2.7.5.jar
ignite-shmem-1.0.0.jar
Ignite-indexing
h2-1.4.197.jar
ignite-indexing-2.7.5.jar
lucene-analyzers-common-7.4.0.jar
lucene-core-7.4.0.jar
lucene-queryparser-7.4.0.jar
Ignite-jta
ignite-jta-2.7.5.jar
ignite-kafka
connect-api-1.1.1.jar
ignite-kafka-2.7.5.jar
Page 15
TAFJ C a c h e
ignite-spring
commons-logging-1.1.1.jar
ignite-spring-2.7.5.jar
spring-aop-4.3.18.RELEASE.jar
spring-beans-4.3.18.RELEASE.jar
spring-context-4.3.18.RELEASE.jar
spring-core-5.2.4.RELEASE.jar
spring-expression-4.3.18.RELEASE.jar
spring-jdbc-4.3.18.RELEASE.jar
spring-tx-4.3.18.RELEASE.jar
1) Run $TAFJ_HOME/bin/StartIgnite
a. You will be prompted for a keystore password. The defaults that ship with
TAFJ are 3jyh?=%_baT for the keystore and aseiqH197%2 for the Ignite user,
respectively.
In order to use Ignite with Jboss and other application servers, one must correctly set the
CLASSPATH to the Ignite libraries. To do this for JBoss, simply copy the following Ignite jars
to the $TAFJ_HOME/ext directory. (This assumes you have a symbolic link to this directory
in the $JBOSS_HOME/modules/com/Temenos/tafj directory, otherwise you need to copy
each jar in the modules directory).
<resource-root path="./ext/Ignite/ignite-core-2.0.0.jar"/>
<resource-root path="./ext/Ignite/ignite-shmem-2.0.0.jar"/>
<resource-root path="./ext/Ignite/ignite-log4j2-2.0.0.jar"/>
<resource-root path="./ext/Ignite/ignite-spring/ignite-spring-2.0.0.jar"/>
<resource-root path="./ext/Ignite/ignite-spring/commons-logging-1.1.1.jar"/>
<resource-root path="./ext/Ignite/ignite-spring/spring-aop-4.3.7.RELEASE.jar"/>
<resource-root path="./ext/Ignite/ignite-spring/spring-beans-4.3.7.RELEASE.jar"/>
<resource-root path="./ext/Ignite/ignite-spring/spring-context-4.3.7.RELEASE.jar"/>
<resource-root path="./ext/Ignite/ignite-spring/spring-core-4.3.7.RELEASE.jar"/>
<resource-root path="./ext/Ignite/ignite-spring/spring-expression-4.3.7.RELEASE.jar"/>
Page 16
TAFJ C a c h e
<resource-root path="./ext/Ignite/ignite-spring/spring-jdbc-4.3.7.RELEASE.jar"/>
<resource-root path="./ext/Ignite/ignite-spring/spring-tx-4.3.7.RELEASE.jar"/>
<resource-root path="./ext/Ignite/ignite-spring/spring-tx-4.3.7.RELEASE.jar"/>
etc
In addition, because of an error that occurs you must include the following entry under
dependencies.
<dependencies>
<imports>
</imports>
</module>
</dependencies>
Likewise, if you are using Weblogic or Websphere, set the appropriate jars to the
CLASSPATH.
Page 17
TAFJ C a c h e
Igni t e Se c u r i t y
Below is a flowchart to accompany the description of TAFJ Caching security. It shows how
properties are loaded, how the keystore is accessed, and how user password must match. It
does not describe the white-listing process.
Start Is keystore
password a
Sys property
or Env
Client or variable? YES
NO
Server
Get database
Load Keystore properties and
Keystore password Ignite
from YES
correct ? password from
classpath keystore
Are Was a
Properties datsource
NO NO
Loaded? passed?
Ask user
for
keystore Read
YES password. Properties Load
from Initializer
Encryption
TAFJ_CACHE NO TAFJ_KS_CAC
YES Initializer Worked?
Return _CONFIG or HE_INIT
loaded?
properties Properties
NO file
End
YES
Decrypt Ignite
YES password from
Password database or Initialize
YES
match props file Encrypter
keystore?
Failure
NO NO
Apache Ignite does not ship with security by default, so Temenos has added its own.
Caching properties can be read/written from a database or the caching.properties file. To
read them from the database, start the JVM with –Dcache.configuration=<<configurationId of
the TAFJ_CACHE_CONFIG table>>.
Nodes joining the cluster must provide a keystore password. Once the keystore is securely
accessed, the node is authenticated by 1) ip address (independent of Apache Ignite’s IP
checking) and 2) a unencrypted password stored in a java key store that is matched against
an encrypted one in either the database or properties file. Database connection properties
are stored in the java key store.
IP Ch e c k i n g
A node starting will be authenticated by the property temn.cache.ignite.allowed.ips. The
node starting must be an ip recognized in one of these properties. Ignite itself has its own ip
checking, but this is added security.
temn.cache.ignite.allowed.ips=10.41.5.51
So for the above ip 10.41.5.51 is allowed to be part of the Ignite grid. If the properties are in
the database (ie. Starting the JVM with –Dcache.configuration=<<some value>>) the
database must be updated.
Page 18
TAFJ C a c h e
SQL> commit;
Pas s w o r d Aut h e n t i c a t i o n
An Ignite user password is stored within the keystore file
$TAFJ_HOME/conf/cache/cachestore.keystore file. The initial password is encrypted on disk
in the $TAFJ_HOME/conf/cache/caching.properties file or database and compared against
the password in the keystore when a node starts up.
The caching framework decrypts the Ignite user password by using an initializer. This
initializer is retrieved from the database. The reason for so doing is that the database has
the ability to encrypt tables and tablespaces to provide another layer of security. To find out
how to encrypt a table please see your specific database documentation. If no data is found
in the TAFJ_CACHE_KS_INIT table, there will be a Security Exception thrown. The caching
framework tries to speak with the database through the T24 datasource. If you are NOT in
an application server context, the following caching properties are retrieved from the
keystore:
temn.tafj.jdbc.url=
temn.tafj.jdbc.driver=
temn.tafj.jdbc.username=
temn.tafj.jdbc.password=
Again, the above properties are only used in a standalone mode where you are outside the
application server context.
Cac h e Enc r y p t i o n
String values (not keys) in all of the Ignite caches are encrypted with the encryption algorithm
stored in the Java key store $TAFJ_HOME/conf/cache/cachestore.keystore file with the key
temn.tafj.cache.ignite.encryption.algo. The value of this key is the encryption algorithm that
will be used for encrypting data in the caches and to decrypt the Ignite user password. The
initializer for that algorithm is stored in the T24 database in the table
TAFJ_CACHE_KS_INIT.
Data can be encrypted going in and out of the cache with objects as well. Not all objects and
all fields are encrypted, however, due to the overhead involved. Encrypting objects is
controlled by the temn.cache.encrypt.objects.stringtypes property. Setting this to true will
encrypt object fields going in and out of the cache if set to true and the field is annotated. To
encrypt an object fields, the object much implement the
com.temenos.tafj.cache.models.Encrypted interface and annotate the fields that should be
encrypted (only char[], byte[], and String types are allowed). For example:
Page 19
TAFJ C a c h e
@Encrypt
etc
The field eventData will be encrypted because it is annotated. Other fields will not be
encrypted. Once an object is put into the cache, its annotated fields will be encrypted. An
object’s state can be queried with a call to isEncrypted(). An object will be decrypted
automatically with a call to the cache get(key). If the cache being written to is write-through
or write-behind, the data going to the database will not be encrypted. It is the job of the
database to encrypt data. If a cachestore writing to a database must be implemented, it
must consider that the data inside the cache is encrypted before it is written to the database
and decrypt it.
h2default-keystore.txt
ignite=aseiqH197%2
temn.tafj.cache.ignite.encryption.algo=AES
temn.tafj.jdbc.password=t24
temn.tafj.jdbc.username=t24
temn.tafj.jdbc.url=jdbc:h2:tcp://localhost/DEV;MVCC=TRUE;DB_CLOSE_ON_EXIT=F
ALSE;MODE=Oracle;TRACE_LEVEL_FILE=0;TRACE_LEVEL_SYSTEM_OUT=0;FILE_LOCK=NO;I
FEXISTS=TRUE;CACHE_SIZE=131072
temn.tafj.jdbc.driver=org.h2.Driver
Ma n i p u l a t i n g th e cac h e s t o r e . k e y s t o r e file
Note that IBM JDK does not support the default keystore include in the distribution.
If you would like to change the encryption algo, Ignite password, or anything else contained
within the keystore, use the command tKeyStore in $TAFJ_HOME/bin. Examples follow.
To create the default file (note that % escapes % character for Windows as below):
Page 20
TAFJ C a c h e
Note that if it is the IBM JDK and you receive the “java.security.NoSuchAlgorithmException:
PBE SecretKeyFactory not available” you will have to download the library for it or change
the security provider to Sun.
To add or change the JDBC password. (If the keystore doesn’t exist it will be created.)
To add or change the Ignite user and password. (If the keystore doesn’t exist it will be
created.)
To add or change the encryption algo (valid values are AES, DES, DES3, RC2, and
BLOWFISH)
will produce:
To read your keystore, use Java’s keytool. You will get output similar to the following.
Igni t e Log g i n g
Ignite creates its own logging object, so ignite-log4j2-<<version>>.jar must be copied to
$TAFJ_HOME/ext directory and included in the CLASSPATH for any application server to
get specific ignite logs. In $TAFJ_HOME/conf/TAFJTrace.properties, an IGNITE appender is
set up to control log level.
Page 21
TAFJ C a c h e
<subsystem xmlns="urn:jboss:domain:naming:2.0">
<remote-naming/>
<bindings>
</bindings>
</subsystem>
After doing this in your standalone-full.xml, when setting the property below in
caching.properties, Ignite threads within the JBoss JVM will use the appserver datasource.
temn.tafj.cache.datasource=java:global/jdbc/t24DS
As well, Ignite JTA jars are necessary if you want to enlist Ignite with the appserver JTA
processor. The current jars needed in the module.xml file for TAFJ to make Ignite work
include:
<resource-root path="/ext/Ignite/ignite-core-2.1.0.jar"/>
<resource-root path="/ext/Ignite/ignite-shmem-1.0.0.jar"/>
<resource-root path="/ext/Ignite/ignite-log4j2-2.1.0.jar"/>
<resource-root path="/ext/Ignite/ignite-spring/ignite-spring-2.1.0.jar"/>
<resource-root path="/ext/Ignite/ignite-spring/commons-logging-1.1.1.jar"/>
<resource-root path="/ext/Ignite/ignite-spring/spring-aop-4.3.7.RELEASE.jar"/>
<resource-root path="/ext/Ignite/ignite-spring/spring-beans-4.3.7.RELEASE.jar"/>
<resource-root path="/ext/Ignite/ignite-spring/spring-context-4.3.7.RELEASE.jar"/>
Page 22
TAFJ C a c h e
<resource-root path="/ext/Ignite/ignite-spring/spring-core-4.3.7.RELEASE.jar"/>
<resource-root path="/ext/Ignite/ignite-spring/spring-expression-4.3.7.RELEASE.jar"/>
<resource-root path="/ext/Ignite/ignite-spring/spring-jdbc-4.3.7.RELEASE.jar"/>
<resource-root path="/ext/Ignite/ignite-spring/spring-tx-4.3.7.RELEASE.jar"/>
<resource-root path="/ext/Ignite/ignite-spring/spring-tx-4.3.7.RELEASE.jar"/>
<resource-root path="/ext/Ignite/ignite-jta/ignite-jta-2.1.0.jar"/>
Page 23
TAFJ C a c h e
Sta n d a l o n e Clie n t s
For clients running pure java client programs such as tRun with Coherence clusters inside or
outside of Weblogic, you must uncomment the following line in tafj_conf.bat (sh) to set up the
JVM properties.
All Clie n t s
The value in CACHENAME for the particular table, matches to a defined cache setup in
Oracle Coherence. For standalone mode (not in a Weblogic application server), this file is
$TAFJ_HOME/conf/cache/tafj-cache-config-client.xml. It must be noted that cache names
must match what is in the TAFJCache.gar file if targeting Coherence within Weblogic.
As you see with the Tables cache used above in the CACHENAME column, this matches the
definition found in tafj-cache-config.xml. These definitions must match or the cache will not
be found.
<?xml version="1.0"?>
<!-- This cache configuration file is for the storage enabled and disabled
Page 24
TAFJ C a c h e
<defaults>
<scope-name>TAFJCache</scope-name>
</defaults>
<caching-scheme-mapping>
<cache-mapping>
<cache-name>Tables</cache-name>
<scheme-name> extend-remote </scheme-name>
</cache-mapping>
</caching-scheme-mapping>
The <scheme-name> will map to an Oracle cache configuration within the same tafj-cache-
config-client.xml. In this case extend-remote refers to a caching scheme on the Coherence
server and was shown earlier in the <remote-cache-scheme> tag.
Once the table is matched within TAFJ (comparing the <cache-name> element against what
is in CACHENAME column in the TAFJ_CACHE table), caching on that table will begin
across a cluster. For Temenos use, “Tables” cacheName should be purely in memory.
Writes on cached data delete the element from the cache, and keys must be re-read. If a
node in the cluster is shutdown, it’s elements will also be removed from the cache (if the data
is not using a replicated scheme), and the data will have to be re-read by other nodes. Using
replicated data does incur a performance cost especially with writing to caches, so be sure
that is the scheme you want to use.
This document does not cover Coherence cache setup (link below). One must be very
careful not to exceed memory assigned and must setup the appropriate expiry times for data
to be refreshed. Again, when data is being written within T24 for a particular record and that
record is cached, the cache is emptied of that key so subsequent reads will get fresh data.
https://docs.oracle.com/middleware/1221/coherence/develop-applications/GUID-2EF76F2B-
ABF2-43AC-BF47-A600564465A2.htm#COHDG5055
Log g i n g Coh e r e n c e
In standalone mode, $TAFJ_HOME/bin/tafj_conf.bat (sh) the following properties are set so
coherence logs to the COHERENCE appender in TAFJTrace.properties. If you want
maximum logging, set coherence.log.level=9
-Dcoherence.log=log4j -Dcoherence.log.level=1
Appender in TAFJTrace.properties:
log4j.logger.Coherence=INFO, coherence
Page 25
TAFJ C a c h e
<module>
<name>TAFJCache</name>
<type>GAR</type>
<path>TAFJCache.gar</path>
</module>
1) One should not expect to write data to the database and expect the application server
to know about it if that data is cached at the application server. Hence, it is very
dangerous to write data outside of an application server context where data is
cached.
In order to run in standalone mode, one must have at least one coherence server running
(you can have multiple if desired). COHERENCE_HOME is the install directory of
Coherence, for example:
Now uncomment the following like in tafj_conf.bat or tafj_conf.sh and run tRun or whatever
program from %TAFJ_HOME%\bin.
Page 26
TAFJ C a c h e
Mon i t o r i n g Coh e r e n c e
See the following instructional video by Oracle how to monitor Coherence caches through
jVisualVM.
https://www.youtube.com/watch?v=0BvkFFlZ000
For EAP version 6 and up, one first has to download jboss-datagrid-6.6.0-eap-modules-
library.zip (or above) from Red Hat and unzip it on top of $JBOSS_HOME. These modules
are put into a separate slot (ie, jdg-6.6) and must be referenced by the tafj module definition
file.
<dependencies>
Etc.
Edit the file with the caches added for T24 from the original configuration. Example:
<subsystem xmlns="urn:infinispan:server:core:6.4">
Page 27
TAFJ C a c h e
<transaction mode="NONE"/>
</local-cache>
<transaction mode="NONE"/>
</local-cache>
</cache-container>
</replicated-cache>
remote-timeout="60000" start="EAGER">
</replicated-cache>
Communication from the EAP appserver to the Jboss Data Grid server occurs through a
HotRod client. Your configuration for Jboss Data Grid Server should depend on what your
EAP configuration is. For example if you have a clustered EAP with two nodes and each
Page 28
TAFJ C a c h e
node exists on a separate machine, you might want a clustered Jboss Data Grid Server set
up to match the EAP configuration and use replicated caches. Refer to the Jboss Data Grid
manual for more information.
Note that you must start your jBoss Data Grid on a port offset to avoid conflicts, ie.
Note the port HodRod starts on as it must match the value in your caching.properties:
In caching.properties
………………………………..
temn.cache.jboss.jdg.port = 11322
Page 29
TAFJ C a c h e
Start with a new or existing WAS profile. Then augment the profile for ExtremeScale. Do
this with the Websphere Customization Toolbox which under the profile’s start menu “First
Steps.”
Page 30
TAFJ C a c h e
Install Extreme Scale somewhere. This becomes $ES_HOME. The code within WAS will
act as a client to this server.
<objectGridConfig xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://ibm.com/ws/objectgrid/config ../objectGrid.xsd"
xmlns="http://ibm.com/ws/objectgrid/config">
<objectGridConfig xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://ibm.com/ws/objectgrid/config ../objectGrid.xsd"
xmlns="http://ibm.com/ws/objectgrid/config">
Page 31
TAFJ C a c h e
<objectGrids>
txIsolation="READ_COMMITTED">
lockStrategy="PESSIMISTIC" lockTimeout="2400000"
numberOfLockBuckets="100"
nullValuesSupported="false" />
</objectGrid>
txIsolation="READ_COMMITTED">
lockStrategy="PESSIMISTIC"
nullValuesSupported="false" />
</objectGrid>
</objectGrids>
</objectGridConfig>
<deploymentPolicy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://ibm.com/ws/objectgrid/deploymentPolicy
../deploymentPolicy.xsd"
xmlns="http://ibm.com/ws/objectgrid/deploymentPolicy">
<objectgridDeployment objectgridName="MemoryLockingCacheGrid">
Page 32
TAFJ C a c h e
<map ref="MemoryLockingCache"/>
</mapSet>
</objectgridDeployment>
<objectgridDeployment objectgridName="TablesGrid">
<map ref="Tables"/>
</mapSet>
</objectgridDeployment>
</deploymentPolicy>
Page 33
TAFJ C a c h e
Star ti n g a Cont a i n e r
In $ES_HOME/ObjectGrid/gettingstarted, run “startcontainer.bat (sh) TemenosGrid”. Then
run “startcontainer.bat MemoryLockingCacheGrid.”
Now you should have a catalog and two containers running, let’s now connect to it through
Websphere.
It should look like the below when finished. Check that the connection works. If it doesn’t
check the ports as previously explained.
Page 34
TAFJ C a c h e
If you have set your tafj.properties correctly as explained in “Property Setup” you should see
information going to $TAFJ_HOME/log/cache.log (if loglevel is set to DEBUG). Example:
[INFO ] 2016-08-05 15:10:37,671 [SIBJMSRAThreadPool : 1] CACHE - Connecting with domain manager in app
server mode for domain: DefaultDomain
If you’ve done the above steps, and if your properties and tables are set up correctly, you
should be able to run T24 programs and see Caching happening with the cache.log file in
$TAFJ_HOME/log if the CACHE logger is set to DEBUG.
import com.temenos.tafj.cache.CacheConstants;
import com.temenos.tafj.cache.CacheParameters;
import com.temenos.tafj.cache.ITAFJCache;
import com.temenos.tafj.cache.TAFJCacheFactory;
//params.setCacheProvider(CacheConstants.CACHE_PROVIDER_TEMENOS_LOCAL);
//params.setCacheProvider(CacheConstants.CACHE_PROVIDER_JBOSS);
//params.setCacheProvider(CacheConstants.CACHE_PROVIDER_COHERENCE);
params.setCacheProvider(CacheConstants.CACHE_PROVIDER_WAS);
Page 35
TAFJ C a c h e
// Alternatively...
//params.setCacheProvider(TAFJCacheFactory.getCacheProperties().getProperty
// (CacheConstants.KEY_PROP_CACHE_EXTERNAL_CACHING_PROVIDER));
cache.put("Key1", "Value1");
System.out.println(value);
Above, a CacheParameters object is created and a provider is chosen (in this case WAS, so
extremeScale is the target cache server so objectgrid.jar would be a dependency).
Alternatively, the provider could have been retrieved from the caching.properties file.
Properties set on the CacheParameters object will be overridden by any properties unless
setOverrideParams(true) is called. Once a cache is retrieved by the TAFJCacheFactory, use
it to cache your objects.
Mon i t o r i n g Cac h i n g
One can monitor cache time in the TAFJ monitor by comparing cache read time against
regular read time and number of cache reads against number of regular reads as shown
below.
Page 36
TAFJ C a c h e
App e n d i x
Int e g r a t i n g TAFJCac h e Apac h e Ignit e se t u p wit h Dat a Eve n t
Str e a m i n g
The Data Event Streaming product can be integrated with Temenos T24 system’s
F.DATA.EVENTS table to cache all records from this table. This is advantageous to 1)
Offload work from the OLTP T24 database 2) Cache the records before the Event Processor
in the Data Event Streaming product needs them so they are available without having to go
back to the database. To set this up:
2) Depending on the DES environment you are running, set the property for the
Ignite configuration file which exists in data-repository-core.jar for the application
server.
a. -Dtemn.cache.ignite.conf.file.name=des-ignite-cache.xml OR
b. -Dtemn.cache.ignite.conf.file.name=des-ignite-cache-secure-ssl.xml
3) On the T24 server, insert the following into the TAFJ_CACHE table and commit.
4) If data is written to different company tables, repeat step two for each of the
company tables, ie. FBNK_DATA_EVENTS, FEU1_DATA_EVENTS, etc
5) Depending on whether or not you are running the application server as an Ignite
server. If running as a client, then -Dtemn.tafj.cache.ignite.server.mode=false.
Start an Ignite server if one is not started. To do this in the DES product, go to the
data-repository-server folder and type start-application.bat(sh). Items cached and
written from the TAFJ system to FDataEventCache will be read by the Data Event
Streaming Event Processor from this same cache.
7) If writing FDataEvents object to the cache (specific for DES), then set:
temn.cache.use.des.for.f.data.events=true AND
temn.tafj.runtime.use.df.cache=true
Page 37