Re: [Pbwebgui-development] quick temperature check

[David S. <dp...@di...>]

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