There are transactional isolations (read committed, repeatable read,etc).. (
http://docs.oracle.com/cd/E19226-01/820-7695/beamv/index.html) . We use
read committed.
If you read without a transaction block, you will get to see all committed
data in the database. Which is the correct
Hi Sumedha,
Please find my comments in-line.
On Wed, Aug 20, 2014 at 12:37 AM, Sumedha Rubasinghe sume...@wso2.com
wrote:
There are transactional isolations (read committed, repeatable read,etc)..
(http://docs.oracle.com/cd/E19226-01/820-7695/beamv/index.html) . We use
read committed.
If
Hi Subash,
Ah! forgot to discuss this today when we chatted.
Subash the get() itself is a call spanning across multiple tables and for
the sake of a DB-neutral implementation we have kept the queries basic. So
this means we handle some joins etc at application-level. This is why it
has to be
Senaka,
I don't think doing a SELECT inside transaction here is required. We just
read the committed data @ the time of reading. That's it.
We never SELECT records for UPDATES (which is one occurrence where doing a
SELECT inside transaction is useful). Another common usecase if to read
Hi Sumedha,
Alright but this SELECT is across different tables, and I also happened to
find this, [1]. So, unless you are in a transaction, if somebody updates
while you read, you can end up having messed up data right?
[1]
Further to above, since we have row-locking I'm hopeful that we cannot
endup with a dirty read as explained in [1], with the current setup. Am I
missing something?
[1] http://msdn.microsoft.com/en-us/library/ms173763.aspx
Thanks,
Senaka.
On Mon, Aug 18, 2014 at 11:36 PM, Senaka Fernando
Hi Senaka et al,
Is there any particular reason for doing $subject ? Because transactional
db connection is always heavy and many applications doing the GET quite
frequently. IMO we should not be doing a read in a transactional manner.
Pls correct me if I am missing something.
I am referring
