On 1 February 2011 16:55, Clifford Heath <[email protected]> wrote:
> On 01/02/2011, at 4:50 PM, Daniel N wrote: > >> The transactions kinda work that way. Your database server will write to >> the db in a non-commited way while you're inside a transaction block. This >> means that if you're trying to read the database from another connection, >> like the cli or navicat, the data won't be there until the transcaction >> block is all done. It's done this way to prevent reads happening, and then >> the transaction fails. The transaction is only 'pre' written inside the >> transaction block (i.e. it's written as far as that connection is concerned) >> and then when it's done it's finally committed... >> > > And until it's committed, if you try to read it, you will *block* or fail > on a timeout/deadlock. > What *won't* happen is that you get to see the data in either the before or > after state. > > Clifford Heath. > How do you mean Cliff? Do you mean from the connection inside the transaction that it can't be read? > > -- > You received this message because you are subscribed to the Google Groups > "Ruby or Rails Oceania" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<rails-oceania%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/rails-oceania?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
