[gradebook2-dev] MySQL transactions

Jon Gorrono jpgorrono at ucdavis.edu
Fri Feb 3 20:05:38 PST 2012


Jeremy,

GB2 has largely the same settings for db transactions as does edu-services

One exception is

<prop key="deleteUserConfiguration">PROPAGATION_NOT_SUPPORTED</prop>

added to the transaction manager bean

This is a complete mystery to me... I can't find any documentation
about this attribute... I have to guess that it is ignored.

Putting that aside.... I wonder what kind of transaction we are
referring to here.... there are transactions from the perspective of
the data source per se and then there are are sessions and
transactions at the hibernate level and, IIUC, these are manage in
very different ways....

It may be that what you are seeing is a confusion at the hibernate
layer, but I can't be sure.... I am not really groking your switching
architecture.

It is possible that hibernate would create new sessions during a
request, for example, if the request uses hibernate in a complicated
way... GB2 may fit that model.... I would suggest trying to add a
OpenSessionInView filter to GB2, perhaps just for the rest servlet,
for your environment to see if that helps.

WDYT?






On Thu, Feb 2, 2012 at 2:07 PM, Kusnetz, Jeremy <JKusnetz at apus.edu> wrote:
> We are working on a project to scale up our MySQL instance by incorporating
> some read/write splitting to a master MySQL node and multiple slave nodes.
> The main theory is writes should go the master and reads should go to the
> slaves (which are replicating from the master).  If writes and reads are all
> incorporated within a transaction, then all the writes AND reads from that
> transaction should all go to the master.  This prevents problems dealing
> with replication latency.
>
>
>
> Everything seems to be working well in Sakai, except for Gradebook2.
>
>
>
> I haven’t looked at the code yet, but the way it’s acting is if certain
> groups of queries aren’t within transactions.
>
>
>
> So for example if you remove an item, all the remaining items within the
> category should automatically update their weights.  But when we have r/w
> splitting enabled, this doesn’t happen all of the time.  Sometimes the item
> will go away, but the remaining items won’t update their weights.  Again
> without looking it looks like the update of the item to set it as deleted is
> not in a transaction with updating the remaining item’s weight values.  If
> all of these were in a transaction then all the updates and selects would
> hit the master node which would obviously be in sync with itself.
>
>
>
> Any thoughts?
>
>
>
> Jeremy Kusnetz | Sr. Systems Engineer
>
>
>
> American Public University System
> American Military University  |  American Public University
> 661 S George Street, Charles Town, WV 25414
> T 304-885-5333 | M 703-967-5212 |  jkusnetz at apus.edu| www.apus.edu
>
>
>
> This message is private and confidential. If you have received it in error,
> please notify the sender and remove it from your system.
>
> _______________________________________________
> gradebook2-dev mailing list
> gradebook2-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/gradebook2-dev
>



-- 
Jon Gorrono
PGP Key: 0x5434509D -
http{pgp.mit.edu:11371/pks/lookup?search=0x5434509D&op=index}
GSWoT Introducer - {GSWoT:US75 5434509D Jon P. Gorrono <jpgorrono -
www.gswot.org>}
http{middleware.ucdavis.edu}


More information about the gradebook2-dev mailing list