I would guess that Witango's stance on the issue would be that it should be
a connector/server issue. You can failover SQL servers in a few ways, so I
don't think you'll get anything more than DSN level control over you db
connection from Witango.

It's clear to me, however that if you did pull your queries out into a TCF
call you could then do all the math there in the TCF. If you passed a full
statement, you could easily see if it contained "select, update, insert,
etc" and then use the appropriate DSN in a DirectODBC. Otherwise, you would
pass in separate parameters for each piece of the statement, what table,
column list, criteria, values, etc. Then the TCF would determine the best
action, what DSN, etc, and then return the resultset naturally. If this was
done with enough complexity you could continue to use the Witango DB actions
in the TCF.

It also seems likely to me that if you were going to do this for load
sharing (not for fail over) that you would just need to load share a few of
the most hit actions. If this is the case, it might be ok to simply have one
slave setup just to answer your most common or most complex request, and
then leave the master to do all the other (and admin) work. When you scale
there's always a step from 'one' to 'two', which is usually a different kind
of step from 'two' to 'many'. More times then not I've found the 'two' case
to be good enough for me, and it can usually be manually handled.

Robert

-----Original Message-----
From: William M Conlon [mailto:[EMAIL PROTECTED] 
Sent: Friday, January 13, 2006 1:27 PM
To: [email protected]
Subject: Re: Witango-Talk: replicated database servers

ok, I see how you would abstract this and replace DirectDBMS, for  
example, with a method call specifying a DSN, query, and  pass a  
variable to receive the resultset.  It seems like you also need to  
tell the object whether it's a read or write query so it doesn't have  
to parse the request.

Or maybe you only use this for the slaves (reading)?  Because part of  
the complexity is working around the inability of <@BIND> to insert/ 
update columns larger than 32k.  So far I can only get this to work  
with Insert/Update actions.

Since you've implemented this, have you suggested any feature  
enhancements for version 6?  It really seems to me that the app  
should be insulated from the db servers, so in the ideal case,  
witango would manage a DSN pool, each with a connection pool.

bill

On Jan 13, 2006, at 10:13 AM, Robert Garcia wrote:

> We have this setup using primebase replication. We wrote our own  
> code in witango, to manage it, it is held in a custom global scope,  
> and allows us to change the reads on the fly accross applications  
> in case a slave dies.
>
> -- 
>
> Robert Garcia
> President - BigHead Technology
> VP Application Development - eventpix.com
> 13653 West Park Dr
> Magalia, Ca 95954
> ph: 530.645.4040 x222 fax: 530.645.4040
> [EMAIL PROTECTED] - [EMAIL PROTECTED]
> http://bighead.net/ - http://eventpix.com/
>
> On Jan 13, 2006, at 9:41 AM, William M Conlon wrote:
>
>> Yeah, I was thinking would have to set up two DSNs and have my  
>> code explicitly choose the master for writing.  But selecting a  
>> slave for reading should be handled by something that manages DSN  
>> connections.  Maybe it shouldn't be witango, but rather an  
>> enhanced DB connector (J/ODBC), so when there are many slaves it's  
>> transparent to the application -- kind of like multiple witango  
>> servers.
>>
>>
>> On Jan 13, 2006, at 9:29 AM, John McGowan wrote:
>>
>>> I was thinking about using my L4 load balancer to handle this  
>>> type of stuff, but of course the load balancer can't really tell  
>>> the difference between a read and a write.  So I was thinking  
>>> that I might have to setup two DSN's if I wanted this type of  
>>> support. one that would be load balanced, and another that would  
>>> only go to the master.
>>>
>>> Of course that would require me to do some rewriting or search  
>>> and replacing of my existing code.
>>>
>>> /John
>>>
>>>
>>>
>>> William M Conlon wrote:
>>>> I was reading up on mySQL database replication (master and  
>>>> slaves), and was curious whether witango had any facilities to  
>>>> support replicated db clusters.  I was thinking something in the  
>>>> dsconfig.ini, maybe that would specify the master (for writes)  
>>>> and the slaves (for reads).
>>>>
>>>> Then we could just refer to our DSN and let witango figure out  
>>>> where to connect.
>>>> ___________________________________________________________________ 
>>>> _____
>>>> TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
>>>>
>>> ____________________________________________________________________ 
>>> ____
>>> TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
>>
>> Bill
>>
>> William M. Conlon, P.E., Ph.D.
>> To the Point
>> 345 California Avenue Suite 2
>> Palo Alto, CA 94306
>>    vox:  650.327.2175 (direct)
>>    fax:  650.329.8335
>> mobile:  650.906.9929
>> e-mail:  mailto:[EMAIL PROTECTED]
>>    web:  http://www.tothept.com
>>
>> _____________________________________________________________________ 
>> ___
>> TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
>>
>
> ______________________________________________________________________ 
> __
> TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf

Bill

William M. Conlon, P.E., Ph.D.
To the Point
345 California Avenue Suite 2
Palo Alto, CA 94306
    vox:  650.327.2175 (direct)
    fax:  650.329.8335
mobile:  650.906.9929
e-mail:  mailto:[EMAIL PROTECTED]
    web:  http://www.tothept.com

________________________________________________________________________
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf

________________________________________________________________________
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf

Reply via email to