IBM E02HMLL-I Implementation Guide - Page 293

Caching, static, relationships, Using, database, connection, pools, memory, checker, thread

Page 293 highlights

Caching static relationships You can cache static relationships so that the participant data they contain is loaded into memory and any queries for the data are issued against the in-memory data, rather than in the data stored in the database. This can make the relationship lookups much faster than if they had to retrieve the information from the database for each flow. For more information on configuring static relationships to be cached, see the Map Development Guide. Using database connection pools It is common to have to retrieve or insert information into a database table during the processing of a flow. Performance is impacted if the interface must establish a connection to the database for each flow, particularly because the log in process must be performed for each connection. Database connection pools are integration components that establish and maintain a pool of connections to a database resource. The connections are established initially and are available to other components to issue queries against the database resource. When a component is done using a connection, the connection is released and returned to the pool so that another component may use it. This eliminates the need to log in each time a connection is required. For information on how to create database connection pools, see Chapter 8, "Configuring database connection pools," on page 145. For information on how to use database connection pools in maps, see the Map Development Guide. For information on how to use database connection pools in collaboration templates, see the Collaboration Development Guide. Using the memory checker thread InterChange Server Express features a memory checker thread that you can use to regulate how events are processed by the system and thereby regulate the consumption of system memory. This can mitigate the risk of system crashes due to lack of memory. The memory checker thread periodically measures the amount of memory used by InterChange Server Express and evaluates if it is within an acceptable configured range. If memory usage is not within an acceptable range then the memory checker thread manages system components to reduce the memory usage. If the memory usage exceeds a lower threshold specified by the lower threshold then the memory checker thread causes the event listener threads of the connector controllers in the system to sleep for a configurable maximum amount of time. The amount of time varies depending on how much the memory usage exceeds the lower threshold, but does not exceed the amount of time specified by the Connector pause time at threshold property. By causing the event listener threads to sleep in this way, the memory checker thread slows down the rate at which events are delivered to InterChange Server Express and reduces the risk of the upper memory threshold being exceeded. If the memory usage exceeds the upper threshold specified by the Memory lower threshold percent property then the memory checker thread pauses the connectors in the system. When connectors are paused they continue to process business Chapter 14. Performance tuning 281

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81
  • 82
  • 83
  • 84
  • 85
  • 86
  • 87
  • 88
  • 89
  • 90
  • 91
  • 92
  • 93
  • 94
  • 95
  • 96
  • 97
  • 98
  • 99
  • 100
  • 101
  • 102
  • 103
  • 104
  • 105
  • 106
  • 107
  • 108
  • 109
  • 110
  • 111
  • 112
  • 113
  • 114
  • 115
  • 116
  • 117
  • 118
  • 119
  • 120
  • 121
  • 122
  • 123
  • 124
  • 125
  • 126
  • 127
  • 128
  • 129
  • 130
  • 131
  • 132
  • 133
  • 134
  • 135
  • 136
  • 137
  • 138
  • 139
  • 140
  • 141
  • 142
  • 143
  • 144
  • 145
  • 146
  • 147
  • 148
  • 149
  • 150
  • 151
  • 152
  • 153
  • 154
  • 155
  • 156
  • 157
  • 158
  • 159
  • 160
  • 161
  • 162
  • 163
  • 164
  • 165
  • 166
  • 167
  • 168
  • 169
  • 170
  • 171
  • 172
  • 173
  • 174
  • 175
  • 176
  • 177
  • 178
  • 179
  • 180
  • 181
  • 182
  • 183
  • 184
  • 185
  • 186
  • 187
  • 188
  • 189
  • 190
  • 191
  • 192
  • 193
  • 194
  • 195
  • 196
  • 197
  • 198
  • 199
  • 200
  • 201
  • 202
  • 203
  • 204
  • 205
  • 206
  • 207
  • 208
  • 209
  • 210
  • 211
  • 212
  • 213
  • 214
  • 215
  • 216
  • 217
  • 218
  • 219
  • 220
  • 221
  • 222
  • 223
  • 224
  • 225
  • 226
  • 227
  • 228
  • 229
  • 230
  • 231
  • 232
  • 233
  • 234
  • 235
  • 236
  • 237
  • 238
  • 239
  • 240
  • 241
  • 242
  • 243
  • 244
  • 245
  • 246
  • 247
  • 248
  • 249
  • 250
  • 251
  • 252
  • 253
  • 254
  • 255
  • 256
  • 257
  • 258
  • 259
  • 260
  • 261
  • 262
  • 263
  • 264
  • 265
  • 266
  • 267
  • 268
  • 269
  • 270
  • 271
  • 272
  • 273
  • 274
  • 275
  • 276
  • 277
  • 278
  • 279
  • 280
  • 281
  • 282
  • 283
  • 284
  • 285
  • 286
  • 287
  • 288
  • 289
  • 290
  • 291
  • 292
  • 293
  • 294
  • 295
  • 296
  • 297
  • 298
  • 299
  • 300
  • 301
  • 302

Caching
static
relationships
You
can
cache
static
relationships
so
that
the
participant
data
they
contain
is
loaded
into
memory
and
any
queries
for
the
data
are
issued
against
the
in-memory
data,
rather
than
in
the
data
stored
in
the
database.
This
can
make
the
relationship
lookups
much
faster
than
if
they
had
to
retrieve
the
information
from
the
database
for
each
flow.
For
more
information
on
configuring
static
relationships
to
be
cached,
see
the
Map
Development
Guide
.
Using
database
connection
pools
It
is
common
to
have
to
retrieve
or
insert
information
into
a
database
table
during
the
processing
of
a
flow.
Performance
is
impacted
if
the
interface
must
establish
a
connection
to
the
database
for
each
flow,
particularly
because
the
log
in
process
must
be
performed
for
each
connection.
Database
connection
pools
are
integration
components
that
establish
and
maintain
a
pool
of
connections
to
a
database
resource.
The
connections
are
established
initially
and
are
available
to
other
components
to
issue
queries
against
the
database
resource.
When
a
component
is
done
using
a
connection,
the
connection
is
released
and
returned
to
the
pool
so
that
another
component
may
use
it.
This
eliminates
the
need
to
log
in
each
time
a
connection
is
required.
For
information
on
how
to
create
database
connection
pools,
see
Chapter
8,
“Configuring
database
connection
pools,”
on
page
145.
For
information
on
how
to
use
database
connection
pools
in
maps,
see
the
Map
Development
Guide
.
For
information
on
how
to
use
database
connection
pools
in
collaboration
templates,
see
the
Collaboration
Development
Guide
.
Using
the
memory
checker
thread
InterChange
Server
Express
features
a
memory
checker
thread
that
you
can
use
to
regulate
how
events
are
processed
by
the
system
and
thereby
regulate
the
consumption
of
system
memory.
This
can
mitigate
the
risk
of
system
crashes
due
to
lack
of
memory.
The
memory
checker
thread
periodically
measures
the
amount
of
memory
used
by
InterChange
Server
Express
and
evaluates
if
it
is
within
an
acceptable
configured
range.
If
memory
usage
is
not
within
an
acceptable
range
then
the
memory
checker
thread
manages
system
components
to
reduce
the
memory
usage.
If
the
memory
usage
exceeds
a
lower
threshold
specified
by
the
lower
threshold
then
the
memory
checker
thread
causes
the
event
listener
threads
of
the
connector
controllers
in
the
system
to
sleep
for
a
configurable
maximum
amount
of
time.
The
amount
of
time
varies
depending
on
how
much
the
memory
usage
exceeds
the
lower
threshold,
but
does
not
exceed
the
amount
of
time
specified
by
the
Connector
pause
time
at
threshold
property.
By
causing
the
event
listener
threads
to
sleep
in
this
way,
the
memory
checker
thread
slows
down
the
rate
at
which
events
are
delivered
to
InterChange
Server
Express
and
reduces
the
risk
of
the
upper
memory
threshold
being
exceeded.
If
the
memory
usage
exceeds
the
upper
threshold
specified
by
the
Memory
lower
threshold
percent
property
then
the
memory
checker
thread
pauses
the
connectors
in
the
system.
When
connectors
are
paused
they
continue
to
process
business
Chapter
14.
Performance
tuning
281