Well, DBI might be more reliable in this one scenario, but for cases where you want cached information stored and called without hitting your database excessively you might want to try and troubleshoot what is going on with qglobals instead so I can fix them for you on the source side.
Some instances that I've ran into myself, is that a qglobal may not get 'updated' or 'refreshed' as you say correctly on the memory side, this can happen with qglobals that have an expire time. If the expire time is unmet and whatever is stored in the memory of that zone is true to that expire time it will not purge those qglobals.
You'd have to reproduce the issue and then use globalview to determine how to reproduce it so we can fix it on the source side. Otherwise, I do think qglobals can be very very useful given that they work correctly.
The thing also with qglobals that is also real nice is that when you use $qglobals{hashkey} it is referencing the memory of the Zone, not hitting the database which is kind of a big performance thing if you think about it.
Whenever a qglobal is set or deleted, then the zone does a refresh and the database is hit for qglobals to be read again and stored back into memory. But when it comes to constant reading of static information qglobals is the way to go, if you're having a consistency issue, I'd love for it to be troubleshot because everyone else is most likely going to experience the same issue.
You expressed whenever a player grabbed a CD key they would go into in instance to have a valid qglobal, that is like you said a refresh issue because the zone is pulling down fresh qglobal information that isn't stored into memory.
I will sift through the code a bit but I would love for this to be reproduced so it can be easily figured out.
Thanks,
Akkadius
|