Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Let me explain the secnario first.

Status
Not open for further replies.

KotiChennayya

Programmer
Oct 3, 2003
15
0
0
IN
Let me explain the secnario first.
I am running a multithreaded application(10 threads) in C.Inside each thread I am creating a TCL interpreter.
After creating the interpreter I am executing a TCL script.Within the script I am logging in
to the Oracle database(I am using ORATCL 3.1 &TCL 8.3) and doing some database operation.So there will be 10 database connection is required(One for each thread)
Now I want to reduce(I cannot keep on increasing # of database connections) this database connections as I need to increase the threads from 10 to 16.
Can I do database pooling with just 4 database connections?These 16 threads will have to share this 4
database connections.The database operations has to be in TCL only.Is there any way to achive this database pooling?
Your solutions are really precious for me.
Thanks in advance.
 
Well, my first inclination is that if possible, I'd write the entire application at the Tcl scripting level using the Thread extension, rather than mucking about with C if I could possibly avoid it. I hate dealing with threads at the C level. And the capabilities of the Thread extension would make your situation relatively simple to deal with.

But assuming that you can't rewrite your application (after all, you've probably got a substantial chunk of C code that you don't want to touch), it can be done. Basically, you'll have 4 threads managing your database connections. Then the other threads will pass messages to the DB threads, and those threads will pass messages back to return the results.

Message passing between Tcl interpreters in different threads is done by adding a special message event to the target interpreter's event queue. This implies that a target interpreter must be managing its event loop (with good, ol' Tcl_DoOneEvent()) for it to notice the message event and process it. To actually send the message, your originating thread calls Tcl_ThreadQueueEvent(); it should then also call Tcl_ThreadAlert() to "wake up" that thread's notifier to alert it to the new event.

- Ken Jones, President, ken@avia-training.com
Avia Training and Consulting, 866-TCL-HELP (866-825-4357) US Toll free
415-643-8692 Voice
415-643-8697 Fax
 
Thank you Mr Jones.
Initially I also thought its better to make my own thread extension.But I have got lot of dependencies which has to be initiated in C ONLY before I do anything.Over that there is a freqent transition of control between C & TCL script.Your suggesstion is an excellent idea.My idea is not to use any OCI or Pro*c for ORACLE database connectivity.If I use 4 threads for DB operations total I will be having 20 threads.If possible I want to avoid this.If there is no other go then I have to implement your option.Sacrificing 16 DB logins for 4 threads definitly a good performance improvement also.
Thank you once again Mr Jones for your prcious time & the suggestion.
Rgds
Koti
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top