Skip to Main Content

Berkeley DB Family

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

[Problem] About : Dbc Retrieve Data in MultiThread

528426Aug 16 2006 — edited Aug 16 2006
Hello,

Our BDB version is 4.0.14 and 4.2.52.

We create our JNI by using BDB C++ API. Under multi-processor,
multithread environment, we do the following operations in the
same Java process:

Db->open()
Dbc->get()
Dbc->put()
Db->close()

After running for 2 hours, when we try to retrieve the data
by using Dbc->get(), it returns error code [DB_NOTFOUND].
In the meantime, another process calls Db->open() and Dbc->get()
and works correctly, without returning any error code.

Would you please tell us how to solve this problem.
Thank you very much.

Comments

Udo
Hi Tammy,

I found out that there seems to be a bug in the listenerAdmin concerning the proper initialization for the config file. If you start the application and try to run listenerAdmin or listenerConfigure, the Listener seems to default to the tmpdir without regarding any other location.
I can now refine my previous post on what exactly has to be done with the current listener to take a config file from a location different that the default tmpdir:

1. create an apex-config.xml
2. place it into the desired directory
3. start the webapp
4. NOT run listenerAdmin, but /apex right away. Only in that part of the Listener there seems to be the proper initialization for the config file. Once you started in /apex, you'll (hopefully) see in your log that the Listener chose the right config file
5. if needed edit the config via listenerAdmin afterwards.

Note that the listenerAdmin still considers itself as unconfigured, though APEX might already be running successfully if the provided config file has the correct parameters.
As soon as you save that configuration (not necessarily changing anything), the Listener stores the "new" configuration (and probably some state information) and from that point on it will always accept that configuration file. If you call listenerAdmin again afterwards, you'll not be able to change the login credentials any more, which would have been possible in the first run.

Quite weird workaround, but it works for me.

-Udo
589721
This workaround works for me - thank you so much. One note that might save some time for others...if you change the default root from apex (or use a different name than apex.war), the URLs provided in the WLS testing page will not work. Just add "/apex" to the end of these URLs. For example: http://host:port/apex_db1/apex

I hope that the process of deploying multiple listeners will be simplified with future releases. I would like the capability to specify different configuration file names, i.e. apex-config-db1.xml, apex-config-db2.xml and to be able to specify these through the listenerAdmin instead of in the web.xml.
Udo
Hi Tammy,

I'm glad you have it working now!
I think, the ease of use for the configuration file already hits for a single instance. But configuring the applications config-file via the application itself might be a bit difficult. Since the Listener is supposed to support multiple J2EE containers: Where would you store the information for the config-file location if not in the web.xml or another (proprietary) static file in the applications context?

-Udo
Arndt Binninger
Hi Udo,

I followed your steps and were able to bring up Listener with correct config location. But when I try to change the database connection parameters via listenerAdmin the fields were greyed out so I'm not able to change them.

Any idea?

Regards,
Arndt
Igor Kortchnoï
Apparently, when one changes the default apex-config.xml location to another one, listenerAdmin's DB connection section (user, password, host, port & SID/service name) becomes protected, but not other sections.
Udo
Hi Anrdt,

it seems that this is the intended behaviour: database configuration is treated as a once-and-forever item. You can of course change the parameters in the config file itself, but the listenerAdmin is never able to edit that part at runtime. I guess this is due to the fact that once you've configured the connection parameters, you have a living connection pool you'd have to reset. This might cause more trouble as this reset might be seen as an invisible side-effect and may not even be supported without application restart on some platforms.

So, if you intentionally want to reconfigure, change the file (or even delete it) or redeploy using another config location.

-Udo
1 - 6
Locked Post
New comments cannot be posted to this locked post.

Post Details

Locked on Sep 13 2006
Added on Aug 16 2006
1 comment
790 views