cancel
Showing results for 
Search instead for 
Did you mean: 

Lookup Tables Perform

Former Member
0 Kudos

Hello to All.

I have a question about Lookup Tables, I have a mapping with that conect a table Extarnal.

so I have a issue because the average that process message is 20 message / second.

So each mapping / mesagge connect to Database an the pool conection increase.

Any help How to resolved this issues.

Thanks and Regards

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

If performance is the issue, then you may want to consider an in-memory caching mechanism. However, if each query to the DB returns a slightly different value, then caching may not help as much. The basic idea is to check the in-memory cache for the value before making the call to the DB. Using the GlobalContainer to cache the results may be helpful, but the values you cache are only available to subsequent calls in the same mapping instance.

http://help.sap.com/saphelp_erp2004/helpdata/en/75/8e0f8f3b0c2e4ea5f8d8f9faa9461a/frameset.htm

This object enables you to cache the values that you want to read again when you next call any user-defined function that is in the same message mapping.

So, the next new message that comes through will have to lookup values in the DB again. The fact that the cache doesnu2019t live past a given mapping is not ideal for performance, but it keeps things simple since you donu2019t really have to worry about stale data getting into your results.

To make a cache available across message mappings we are using an in-memory cache. This cut the per/call time down from around 300ms to near 0ms. We are caching the results from an RFC lookup, but the idea is the same. Of course, you would need to make sure your business process allows for the chance of stale data (value found in the cache, but source actually changed). For us, we have a 15 minute (configurable) window where itu2019s acceptable to use the old values.

I used [JCS|http://jakarta.apache.org/jcs/] from Apache as the caching mechanism at first. It has a long list of features. Most importantly the basics like max cache size, LRU object ejection, and features to clear out old/expired entries. I found it very nice overall. Everything is controlled via a configuration file. You can make it as simple or as complicated as you want. In the end I opted for an extended LinkedHashMap class creating our own LRU cache. This wasnu2019t due to an issue with JCS, but rather to simplify things since we had our own mechanisms to invalidate/purge the cache. Plus, JCS was consuming a little more memory per object stored. I later noticed that there are some NetWeaver caching features (CML).

http://help.sap.com/saphelp_nwce10/helpdata/en/ee/c2c95202b4463195694123645ecde4/content.htm

It looked promising, but I didnu2019t find much info on the topic and simply had to move forward with what was working. Good luck!

-Russ

Answers (3)

Answers (3)

Former Member
0 Kudos

Well.

The main issue is the performance. Many conections are opened.

Maybe I stored in a global container, or maybe use a files in XI.

Any idea how to resolved this.?

Former Member
0 Kudos

can't u store the results in GlobalContainer and reuse for subsequent mappings?

Former Member
0 Kudos

Hello Luis,

What exactly the issue is ? Too many threads opened for the used JDBC adapter ? How are you performing your lookups : XI JDBC adapter or J2EE JDBC connector ?

Rgds

Chris