Geek Answers Handbook

Accessing a database in parallel threads, a viable option?

I have the following situation.

main() { hnd = CreateTHread( func1 ); // Call fun2() wait(hnd); return ; } fun2() { //Access database to perform some read operation on TAble A } func1() { //Access database to perform some read operation on TAble A // Recursive operations }

What I observed, fun2() takes longer to finish if I use the fun2() approach. Maybe because the functions THread func and fuc2 work in the same table. Please note: in both functions there is only a read operation. The AWR report suggested that the number of requests was increased using the threading approach.

+4
source share
4 answers

Similar question - Accessing a database with multiple threads

The Oracle JDBC interfaces, as well as the built-in Oracle drivers (I suppose) are capable of handling multi-threaded requests ( http://www.cs.umbc.edu/portal/help/oracle8/java.815/a64685/tips1.htm )

However, when it comes to implementing a database engine, this is not clear. From the current documentation, I understand that as long as your request is READONLY without the intention to update the lack of locking, and you should see a performance increase (at least a slight one).

However, there are many other factors that determine whether a parallelism engine will be used. Server hardware configuration (multi-core), etc. It can also determine whether the query engine uses a parallel or queued approach.

By the way, how much time difference do you observe in both approaches that you tried. What was the size of your data?

+1
source

Try changing the isolation level to READ COMMITTED and make queries using READ ONLY "clause". It should be less restrictive and allow you to simultaneously view the same tables.

+1
source

Try using two different compounds. A multi-threaded join with the same table would always degrade performance, you put stress on the join itself. You did not specify which driver you use to access, but I tested a similar approach with the JDBC driver in Oracle 10 and had performance degradation, I assume that the SQL commands are somewhat pipelined one after the other if you use the same connection.

+1
source

Concurrency always makes you lose performance. If you need concurrency, you have to live with it; If you do not need it, you should not use it!

Some operations in SQL, such as "count", perform LOCK on tables. Can you share your SQL?

0
source

More articles:


All Articles