[Building Sakai] autocommit

[Charles Hedrick]

I acfually I thought it should always be on, since that's the default,  
but I'd be just as happy having it always off.


On Jul 28, 2009, at 4:21 PM, Speelmon, Lance Day wrote:

> I am a bit rusty here, but we want to ensure that autocommit is never
> enabled.  It creates unpredictable behavior.  Perhaps it would be
> better to introduce code (if needed) that ensures autocommit is always
> off.  Maybe that is what you are saying Chuck?  Best, L
>
>
> Lance Speelmon
> Scholarly Technologist
>
> On Jul 28, 2009, at 11:37 AM, Charles Hedrick wrote:
>
>> I'm a bit interested in how auto-commit it used in Sakai. Code
>> typically does
>>
>> oldcommit = conn.getAutoCommit.
>> conn.setAutoCommit(false);
>>
>> do transacftion
>>
>> conn.commit
>> conn.setautocommit(oldcommit);
>>
>> The problem with this is the it tends to make the normal state of
>> autocommit undefined. All it takes is one application to not put it
>> back, and it ends up false. I've seen a number of cases where either
>> in an error code on sometimes in all causes, the restoration of
>> autocommit is not done.
>>
>> We just ran into a situation in Samigo (deleting uploaded files) that
>> fails in production but works in the 2.6 QA servers. It does an  
>> update
>> without either starting a transaction or committing. This is probably
>> a bug, but in theory doing a single update is OK in autocommit mode.
>> You don't really need a transaction unless you're doing several  
>> things
>> that need to be consistent. However if the system isn't in autocommit
>> mode, a single update without a commit will not have the desired
>> effect.
>>
>> I maintain that we need a convention that says when you're not in a
>> transaction, the system should be autocommit on. Then the code would
>> be
>>
>> conn.setAutoCommit(false);
>>
>> do transacftion
>>
>> conn.commit
>> conn.setautocommit(true)
>>
>> That would be much more likely to leave the system in a known state.
>> However I would also suggest that code ought not to rely on the
>> current state of autocommit, but if you want to use autocommit you
>> should set it. At least with Mysql, the optimal setting on the
>> connector keeps track of the state of autocommit and doesn't send
>> unnecessary ones to the server.
>>
>> Another option, which might result in the  most reliable code, would
>> be to set autocommit to an explicitly random value, 50% true and 50%
>> false. That would make it more likely that code that depends upon the
>> current state of autocommit would be found in testing.
>>
>> _______________________________________________
>> sakai-dev mailing list
>> sakai-dev at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>
>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org
>> with a subject of "unsubscribe"
>