on 11-10-2008 3:21 PM
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
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
can't u store the results in GlobalContainer and reuse for subsequent mappings?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
93 | |
10 | |
10 | |
9 | |
9 | |
7 | |
6 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.