Re: [Pbwebgui-development] quick temperature check

[JT S. <jt...@pl...>]

If you are running multiple databases, which you probably won't be, yes it could take a 
few seconds or even minutes to see your changes. It really depends upon how busy your 
servers are as to how quickly they are resynced.

98% of WebGUI users will never use multiple databases, and therefore won't even know 
that this feature exists, and won't be affected by it.



On Sat, 10 Jul 2004 00:48:09 -0700
  David Schwartz <dp...@di...> wrote:
>When I modify a WG site (in Admin mode), I tend to put some stuff on a page,
>then have a look at it from the "outside" (after logging out) to be sure I got
>all of my security settings correct.  What happens in this situation?  If it
>takes "a while" (are we talking seconds, minutes, or what?) for the slaves to
>get updated, my interpretation of this discussions implies that it's fairly
>likely that none of the changes made in Admin mode will actually be visible for
>"a while".  Or am I missing something?
>
>-David
>
>Christian Zoellin wrote:
>
>> Exactly, and this is, what the tag on the session should take care of
>> (in my suggested solution).
>> As soon as someone updates data (to the master), he get's the most
>> up2date version for all following reads. That way people see the results
>> of THEIR modifications immediately. Turning Admin mode would also set
>> the tag on the session.
>>
>> Transparent and correct.
>> That way, also things like adding USS would work correct (in the sense
>> that no single user would notice any difference). With your solution,
>> the USS wobject will not be able to use any replicants. At least not
>> without the user noticing.
>>
>> I will not need replication in the near future, so how it is implemented
>> is not important, as long as it doesn't break existing wobjects (that
>> don't want to use the feature).
>>
>> Just my 2 cents.
>>
>> Chris
>>
>> JT Smith wrote:
>>
>> > It's already implemented so this is someone of a lame duck discussion,
>> > but I think it's important that everyone understand what's going on.
>> >
>> > Using replicated databases isn't as easy as just all writes go to the
>> > master and all reads come from the slave. There is a such thing as a
>> > high-priority read. Let me give you an example.
>> >
>> > Let's say I'm editing my user profile (I'm not in admin mode). The data
>> > is read from a slave and then when I hit save it's written to the
>> > master. Now it may be a few minutes (or even longer) before the slave is
>> > updates. Let's say I forgot to update my phone number as well. I
>> > immediately go back and edit my profile, which reads from the slave. The
>> > problem here is that my new email address hasn't been written to the
>> > slave yet, so when the form is populated, it get's populated with stale
>> > data, then when I hit save again, my new email address is overwritten
>> > with the old one, but my phone number is up to date.
>> >
>> > Therefore you have reads, writes, and high-priority reads. The latter
>> > two need to come from the master, and only the reads can come from the
>> > slave.
>> >
>> > Then you might say, "Well then, anything that deals with editing must
>> > come from the master." That's also easier said than done. For instance
>> > if you have getter's and setters. The getters are used both to populate
>> > edit forms, and to display data to the user.
>> >
>> > Anyway, all I'm trying to get across is that this isn't a simple flag to
>> > be thrown. It's a decision, that must be made for each query by a human
>> > at coding time. That's the reason why I implemented it in the way I did.
>> >
>> >
>> >
>> >
>> >
>> > On Fri, 09 Jul 2004 22:53:27 +0200
>> >  Christian Zoellin <chr...@zo...> wrote:
>> >
>> >> So, why not transparently use the replicants until an UPDATE, CREATE,
>> >> DELETE etc. statement is issued. After that, there should be a switch
>> >> on the user session to tie the session to the master db.
>> >> That way, users that just read from the database will use the
>> >> replicants and users that change content will always see the most
>> >> up2date version. Only updates to the database for statistics (we
>> >> always have those for the page statistic) would have to be treated
>> >> different in that they don't set the switch.
>> >>
>> >> I think, that would be as transparent as it gets.
>> >>
>> >> Chris
>> >>
>> >>
>> >> JT Smith wrote:
>> >>
>> >>>> 1) Aren't there cases when people will want to update a central
>> >>>> database
>> >>>> but not have admin on? For instance, posting to a "public" message
>> >>>> board. I'm assuming the RDBMS takes care of keeping this in sync? I
>> >>>> haven't had a need to set up replicated DBs yet.
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> Yes there are, but in those cases the developer will the main
>> >>> database and not one of the replicants.
>> >>>
>> >>> In fact, all writes should use the master and not a slave.
>> >>>
>> >>>
>> >>>> 2) Transparency == good, normally.  The more difficult path for you is
>> >>>> probably the simplest for everyone.
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> Could you explain what you mean by that?
>> >>>
>> >>>> What will adding replication do to performance for (an assumed
>> >>>> majority)
>> >>>> of WebGUI users that run only one database?
>> >>>
>> >>>
>> >>>
>> >>> It will do nothing to the performance of the majority. They won't
>> >>> have to set anything up differently or anything else.
>> >>>
>> >>>
>> >>> In fact, I should have mentioned this before, if no slaves are
>> >>> defined then the master will always be used regardless.
>> >>>
>> >>>
>> >>>
>> >>>> On Fri, 2004-07-09 at 10:49, JT Smith wrote:
>> >>>>
>> >>>>> I've been struggling over the last week with how to implement the
>> >>>>> ability to use a replicated database as a read source. I've
>> >>>>> experimented with about 10 different ways of doing this and all
>> >>>>> either didn't work or were way too convoluted to be useful. I've
>> >>>>> come down to two ways to implement this, but I need about 2 seconds
>> >>>>> of feedback from a couple of people on this list to make sure I'm
>> >>>>> on the right track.
>> >>>>>
>> >>>>> Way #1: Refactor WebGUI::SQL Change WebGUI::SQL to not use all
>> >>>>> those class methods, but instead instance methods. So we'd add
>> >>>>> several constructors and remove the ability to pass in a new
>> >>>>> database handler on each seperate method. The new constructors
>> >>>>> would be:
>> >>>>>
>> >>>>> new ( [ dbh ] )
>> >>>>>
>> >>>>> This would default to the WebGUI db handler, but you could override
>> >>>>> it by passing in a dbh. This would be the common one everyone would
>> >>>>> use.
>> >>>>>
>> >>>>> newReplicant ( )
>> >>>>>
>> >>>>> This would use a random one of the defined replicated databases,
>> >>>>> except if the user was in admin mode.
>> >>>>>
>> >>>>>
>> >>>>> newHandler ( dsn, user, pass [ , options ] )
>> >>>>>
>> >>>>> This would create a new DBH and set it in the object instance. And
>> >>>>> would require the use of a disconnect() method to destroy it.
>> >>>>>
>> >>>>>
>> >>>>> So to use any of these you'd do something like this:
>> >>>>>
>> >>>>>
>> >>>>> my $db = WebGUI::SQL->newReplicant;
>> >>>>> my @arr = $db->quickArray($sql);
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> Way #2: Progie does more work, but gets more control We leave
>> >>>>> WebGUI::SQL as is, except for adding one method like:
>> >>>>>
>> >>>>> WebGUI::SQL->getReplicant()
>> >>>>>
>> >>>>>
>> >>>>> Then the programmer in his code would write something like (when he
>> >>>>> wants to use a replicant):
>> >>>>>
>> >>>>> my $dbh = $session{dbh};
>> >>>>> unless ($session{var}{adminOn} || $shouldntUseReplicant) {
>> >>>>>    $dbh = WebGUI::SQL->getReplicant;
>> >>>>> }
>> >>>>> my @arr = WebGUI::SQL->quickAarry($sql,$dbh);
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> Way #1 is cleaner, but requires refactoring all of WebGUI. (which
>> >>>>> I'll do if you guys think this is the best way to go)
>> >>>>>
>> >>>>> Way #2 is not nearly as clean, but requires no change to the rest
>> >>>>> of WebGUI.
>> >>>>>
>> >>>>>
>> >>>>> I hope to implement one of these in a few hours, so quick feedback
>> >>>>> is appreciated.
>> >>>>>
>> >>>>>
>> >>>>> JT ~ Plain Black
>> >>>>>
>> >>>>> Create like a god, command like a king, work like a slave.
>> >>>>>
>> >>>>> -------------------------------------------------------
>> >>>>> This SF.Net email sponsored by Black Hat Briefings & Training.
>> >>>>> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
>> >>>>> digital self defense, top technical experts, no vendor pitches,
>> >>>>> unmatched networking opportunities. Visit www.blackhat.com
>> >>>>> _______________________________________________
>> >>>>> Pbwebgui-development mailing list
>> >>>>> Pbw...@li...
>> >>>>> https://lists.sourceforge.net/lists/listinfo/pbwebgui-development
>> >>>>
>> >>>>
>> >>>> --
>> >>>> *-._.-*^*-._.-*^*-._.-*^*-._.-*^*-._.-*^*-._.-*^*-._.-*^*-._.-*
>> >>>>
>> >>>> Daniel Collis Puro
>> >>>> CTO and Lead Developer, MassLegalServices.org
>> >>>> Massachusetts Law Reform Institute
>> >>>> 99 Chauncy St., Suite 500
>> >>>> Boston, MA 02111
>> >>>> 617-357-0019 ext. 342
>> >>>> dp...@ml...
>> >>>> http://www.masslegalservices.org
>> >>>>
>>
>> -------------------------------------------------------
>> This SF.Net email sponsored by Black Hat Briefings & Training.
>> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
>> digital self defense, top technical experts, no vendor pitches,
>> unmatched networking opportunities. Visit www.blackhat.com
>> _______________________________________________
>> Pbwebgui-development mailing list
>> Pbw...@li...
>> https://lists.sourceforge.net/lists/listinfo/pbwebgui-development
>
>
>
>-------------------------------------------------------
>This SF.Net email sponsored by Black Hat Briefings & Training.
>Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
>digital self defense, top technical experts, no vendor pitches, 
>unmatched networking opportunities. Visit www.blackhat.com
>_______________________________________________
>Pbwebgui-development mailing list
>Pbw...@li...
>https://lists.sourceforge.net/lists/listinfo/pbwebgui-development


JT ~ Plain Black

Create like a god, command like a king, work like a slave.