I guess the oracle administrator has to tuning this value based on real time statistics. The server side should set the maximum connection allow ed. My companies server now set it to 120, we are still testing to see t he real performance. Sometime, the pool size is not quite important, the application can use multi-thread mechanism to synchronizely get the con nection from pool, if the server's performance is good enough, a relativ ely smaller pool size wont kill too much performance. For the da
【在 w*r 的大作中提到】 : I guess the oracle administrator has to tuning this value based on real : time statistics. The server side should set the maximum connection allow : ed. My companies server now set it to 120, we are still testing to see t : he real performance. Sometime, the pool size is not quite important, the : application can use multi-thread mechanism to synchronizely get the con : nection from pool, if the server's performance is good enough, a relativ : ely smaller pool size wont kill too much performance. For the da
Well, to solve this problem is totally depend on your implementation. Generally, I would just use a sql execution threadpool and a sqlTaskQueue to getInstances of the connection and release the instances of connection as soon as possible in your transaction. Oracle has a connection implementation in its JDBC pacakage. To gain the maximum throughput, the sql execution threadpool could be tuned to keep running as fast as possible by keep its connection instances and only release the connection whe
【在 w*r 的大作中提到】 : Well, to solve this problem is totally depend on your implementation. : Generally, I would just use a sql execution threadpool and a sqlTaskQueue to : getInstances of the connection and release the instances of connection as soon : as possible in your transaction. Oracle has a connection implementation in its : JDBC pacakage. To gain the maximum throughput, the sql execution threadpool : could be tuned to keep running as fast as possible by keep its connection : instances and only release the connection whe
w*r
9 楼
dump 3, 3 make things worse, if you need your data updating can be shown in a sort of "real-time" manner, 3 is definitely not a choice at all. Logical Standby would not help your performance issue either, I think your solution could be seperated into several parts, for the application part, you have to make optimization to release the connection to RDBMS as soon as possible(as I described several options in last post) for the server side, to improve the performance, you could try to optimize the
【在 w*r 的大作中提到】 : dump 3, 3 make things worse, if you need your data updating can be shown in a : sort of "real-time" manner, 3 is definitely not a choice at all. Logical : Standby would not help your performance issue either, I think your solution : could be seperated into several parts, for the application part, you have to : make optimization to release the connection to RDBMS as soon as possible(as I : described several options in last post) for the server side, to improve the : performance, you could try to optimize the