async BSFN call from a BSFN

2274646542

Member
Team-
I am trying to call asynchronously a BSFN from another BSFN. I basically want the calling BSFN to trigger the other BSFN just before the end of the code, and finish while the other BSFN runs.

I have come across this API JdeCallObjectThreaded, but it is making unstable my fat client after I run it, I am missing something probably.

Have you used this API? There is a join function that I don't want to call, since I want the BSFN that is calling to continue and finish while the other runs. Do I need to call the join function? If not, what do I do with the handle the first function returns? I am freeing this handle now and maybe I should not.

If you have done this, do you have some sample code on how to use it?

Do you have other suggestions for async BSFN calls?


Thank you
 
You have to call jdeCallObjectThreadedJoin. You basically get a small thread pool. BTW, you must make sure the following is in your jde.ini:
Code:
[JDENET_KERNEL_DEF6]
MaxUserSessionThreads=6

The thread used by jdeCallObjectThreaded is not released back to the pool until you call jdeCallObjectThreadedJoin. Calling jdeCallObjectThreadedJoin probably also releases resources allocated for the response as well, so NOT calling would result in a small memory leak. You should NOT free the thread handle with jdeFree. That is probably why your fat client is "un-stable". The handle is most likely NOT simply a pointer.

Having said all that I have been toying with the idea of seeing if I can come up with a "fire and forget" type call like you describe but have not worked on it. Your best bet for some type of true async, "fire and forget" call to a BSFN from a BSFN is to launch a UBE that calls the desired BSFN - provided of course that the called BSFN doesn't rely on any state information in the user's JDE session like jdeCache, etc.

The only real use for JdeCallObjectThreaded is for performance. For example. I had a form with three grids each with about 10 lines and about 10 columns. So about 300 cells. Each cell was a effectively multiple SQL statements and calculations. I threaded off each cell's logic and improved performance by about 50-75% (with 6 threads... note NOT a complete six fold improvement...). I have also found that there is overhead with the very first call to JdeCallObjectThreaded - most likely creating the user thread pool. Subsequent calls are very quick, but the first call takes a few micro seconds longer - in other words sometimes you can get WORSE performance by trying to thread things off.

I think its really, really cool that Oracle gave us this API and I have used it in about 5 different places, but its use is somewhat limited.
 
Thanks a lot Brian, this makes sense. I have tried with the join, and that seems to work fine. I will use this in the future, but it doesn't solve what I am trying to do now...

The UBE is clearly a way to do it, but the overhead is just too much. Subsystem is also an option, but with similar overhead. I will keep looking, there must be a way to do this with minimum overhead.

Anyone that can provide some ideas would be great.

Thanks
 
Back
Top