[ruby-oci8-devel] propose to implement pooling technology for Ruby-OCI8

shiwei zhang shiwei.zhang at oracle.com
Fri Dec 21 04:29:52 EST 2007


Hi,

shiwei zhang wrote:
> Hi Kubo,
>
> Yes, it's better to make our discussion public on this ML.
>
> KUBO Takehiro wrote:
>> Hi shiwei,
>>
>> Sorry too late to reply you.
>>
>> shiwei zhang <shiwei.zhang at oracle.com> writes:
>>
>>   
>>> How are you? This is Shiwei from Oracle Asia R&D Center, I hope you
>>> still remember me:)
>>>     
>>
>> Yes, of course.
>>
>>   
>>> Last time I submitted through Christ Jones to you a patch about Easy
>>> Connection String in Ruby-OCI8. Now I want to continue contributing
>>> some work for Ruby-OCI8, in order to make it further satisfy Ruby
>>> users.
>>>
>>> These days I did some tentative research about pooling technology for
>>> Ruby-OCI8. Database pooling is a top-notch technology that can improve
>>> the performance of application programs, especially for those
>>> large-scale ones handling many DB requests.
>>>     
>>
>> In general, agree. Connection pooling is good for web applications.
>> PHP offers persistent connections for the purpose.
>>   http://php.net/manual/en/features.persistent-connections.php
>>
>> IMO, most ruby's web applications are built on rails. But as for
>> rails, it is another story. Rails uses only one connection for all
>> requests. Pooling will not improve the performance.
>>
>> BTW go on.
>>   
> Agree. Haha, ruby shouldn't be always limited to Rails, and even 
> shouldn't always limited to web application. Furthermore Rails might 
> change its principle to hold more connections in its pool.  :-)
>>> There are two kinds of pooling at the client side: one is connection
>>> pooling, which can create & destroy stateful sessions; the other is
>>> session pooling, which can reuse stateless sessions. JDBC has supportd
>>> both connection pooling and session pooling, it has classes
>>> OracleOCIConnectionPool and OracleConnectionPoolDataSource. Now I
>>> propose to implement silimar connection pooling and session pooling
>>> for Ruby-OCI8, do you agree? What's your opinion?
>>>     
>>
>> Surely.
>>   
> Great, so I'd like to carry on, both connection pooling and session 
> pooling.
>>   
>>> I've read the related codes in RubyOCI8_1.0.0-rc3, I think we can work
>>> it out by either of the two methods:
>>>     
>>
>> I want to add new features to ruby-oci8 svn trunk, not to ruby-oci8
>> 1.0 seriese. Svn trunk will be ruby-oci8 2.0. And its internal
>> structure is thoroughly changed.
>>
>> The svn trunk code can be checked out with the following command.
>>
>>   svn checkout http://ruby-oci8.rubyforge.org/svn/trunk/ruby-oci8
>>  or
>>   svn checkout svn://rubyforge.org/var/svn/ruby-oci8/trunk/ruby-oci8
>>   
> This morning I downloaded the SVN source codes and glimpsed at it. As 
> you said the internal structure is changed. Actually I wrote some 
> codes locally on my pc about pooling for ruby-oci8_1.0, and I think 
> it's fine for me to move to ruby-oci8_2.0. You transferred more codes 
> from ruby side to C side in the new version, which I think makes the 
> logic easier to decide & process the connection parameters, which is good.
> BTW, I have a small question: you use "OCISessionBegin()" for 
> T_EXPLICIT (external credential or OCI_SYSDBA, OCI_SYSOPER); and use 
> "OCILogon" for T_IMPLICIT (OCI_CRED_RDBMS). *Why don't you use 
> "OCISessionBegin()" for both T_EXPLICIT and  T_IMPLICIT?* I think 
> "OCISessionBegin()" can work for both of the two conditions, do you 
> have other concerns about this?
> I'm sure connection pooling and session pooling support T_IMPLICIT, 
> but I'm not sure whether they also support T_EXPLICIT. And I'm not 
> sure whether it's necessary for T_EXPLICIT to have connection pooling 
> and session pooling, since you know, T_EXPLICIT is used a lot less 
> frequently. I need to investigate more on this.
Today I wrote a program to confirm that the pooling doesn't support 
OCI_SYSDBA or OCI_SYSOPER, it returns "ORA-24300: bad value for mode" 
when using the mode OCI_SYSDBA or OCI_SYSOPER. I will make sure whether 
OCI_CRED_EXT works in pooling soon.
>>> 1. Write sub-classes inherited from the current Ruby class OCI8; and
>>> write some C functions to execute the corresponding pooling work.
>>> 2. Modify the current Ruby class OCI; also write some C functions to
>>> execute the corresponding pooling work.
>>>     
>>
>> Can you show me the spec and usage example?
>> for example:
>>
>>   # connection pool
>>   pool = OCI8::ConnectionPool.new(username, password, tns_name, conn_min, conn_max, conn_incr)
>>   conn = OCI8.new(pool)
>>
>>   # session pool
>>   pool = OCI8::SessionPool.new(username, password, tns_name, sess_min, sess_max)
>>   conn = OCI8.new(pool)
>>   
> For now I think:
>
> # connection pool
> pool = OCI8::ConnectionPool.new(username, password, tns_name, 
> conn_min, conn_max, conn_incr)
> conn = OCI8.new(pool, appusername, apppassword)
> or
> pool = OCI8::ConnectionPool.new(username, password, tns_name, 
> conn_min, conn_max, conn_incr)
> conn = OCI8.new($poolname, appusername, apppassword)
>
> # session pool
> pool = OCI8::SessionPool.new(username, password, tns_name, sess_min, 
> sess_max)
> conn = OCI8.new(pool, appusername, apppassword)
> or
> pool = OCI8::SessionPool.new(username, password, tns_name, sess_min, 
> sess_max)
> conn = OCI8.new($poolname, appusername, apppassword)
>
> Notes:
> username is used to create the pool, it's the implicit user. 
> appusername is used to create/get a session from the pool. appusername 
> could be different with username.
> $poolname is generate from "OCI8::ConnectionPool.new()" or 
> "OCI8::ConnectionPool.new()". If we've gotten the value of $poolname, 
> it's enough for "OCI8.new()" to create/hand out a session for appusername.
>> If you can, please join to ruby-oci8-devel to make our discussion public.
>>
>>   ruby-oci8-devel ML: http://rubyforge.org/mail/?group_id=256
>>
>>   
Thanks & Best Regards,
Shiwei
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/ruby-oci8-devel/attachments/20071221/79b387c2/attachment.html 


More information about the ruby-oci8-devel mailing list