Subject | Re: [firebird-support] What transaction options to use? |
---|---|
Author | Carlos H. Cantu |
Post date | 2004-11-22T23:21:29Z |
For #1:
A) If you allow people to see commited data from other transactions,
you can use ReadCommited isolation.
B) If you want consistent view of data, use snapshot isolation
(tiConcurrency in IBO)
For both A and B, declare the transaction as readonly. I think A will
consume less resources from the server.
For #2:
Use same as B, but configure it as read_write.
A good pratice is to make any transactions as short as possible.
Better results can be achieved using components that bufferize the
data in memory. IBO is great in that aspect.
Carlos
http://www.warmboot.com.br
FireBase - http://www.FireBase.com.br
CZH> Sorry to repost this - it was part of an earlier thread. I know everyone
CZH> here are volunteers - just like the Indy team is but hoping someone can save
CZH> me a LOT of trial and error....
CZH> Basically here is what I need and Im not sure what options to use to achieve
CZH> this. I have two types of transactions.
CZH> 1) Reads. For reads, I don't want them to see anything that has been changed
CZH> since the transaction begun - that is they should see a snapshot as the db
CZH> was when they started their Tx. If possible an erorr should be thrown if I
CZH> attempt to do any writes (inserts or updates) in this type of transaction.
CZH> 2) Updates. Updates should be like reads, but allow me to write. Updates
CZH> should give me an error if I update a row that someone else updated since I
CZH> started my transaction.
CZH> The read is a bit more flexible, in many cases I could allow it to see data
CZH> that has been committed during its transaction. But #2 is really important.
CZH> Before coming to IB - we implemented all this ourselves by adding a version
CZH> to field to each row and issuing updates in the form of Update xxxx where
CZH> version = x and set version = x + 1 If it returned 0 count we knew it failed
CZH> and failed the whole transaction.
CZH> Im trying to perform the same functionality usign FB's built in txs as they
CZH> appear to work in a similar fashion.
CZH> I shoud also not be able to delete a record if someone updated (Committed?)
CZH> it since I started my transaction, and vice versa.
A) If you allow people to see commited data from other transactions,
you can use ReadCommited isolation.
B) If you want consistent view of data, use snapshot isolation
(tiConcurrency in IBO)
For both A and B, declare the transaction as readonly. I think A will
consume less resources from the server.
For #2:
Use same as B, but configure it as read_write.
A good pratice is to make any transactions as short as possible.
Better results can be achieved using components that bufferize the
data in memory. IBO is great in that aspect.
Carlos
http://www.warmboot.com.br
FireBase - http://www.FireBase.com.br
CZH> Sorry to repost this - it was part of an earlier thread. I know everyone
CZH> here are volunteers - just like the Indy team is but hoping someone can save
CZH> me a LOT of trial and error....
CZH> Basically here is what I need and Im not sure what options to use to achieve
CZH> this. I have two types of transactions.
CZH> 1) Reads. For reads, I don't want them to see anything that has been changed
CZH> since the transaction begun - that is they should see a snapshot as the db
CZH> was when they started their Tx. If possible an erorr should be thrown if I
CZH> attempt to do any writes (inserts or updates) in this type of transaction.
CZH> 2) Updates. Updates should be like reads, but allow me to write. Updates
CZH> should give me an error if I update a row that someone else updated since I
CZH> started my transaction.
CZH> The read is a bit more flexible, in many cases I could allow it to see data
CZH> that has been committed during its transaction. But #2 is really important.
CZH> Before coming to IB - we implemented all this ourselves by adding a version
CZH> to field to each row and issuing updates in the form of Update xxxx where
CZH> version = x and set version = x + 1 If it returned 0 count we knew it failed
CZH> and failed the whole transaction.
CZH> Im trying to perform the same functionality usign FB's built in txs as they
CZH> appear to work in a similar fashion.
CZH> I shoud also not be able to delete a record if someone updated (Committed?)
CZH> it since I started my transaction, and vice versa.