Hi Sumedha, Please find my comments in-line.
On Wed, Aug 20, 2014 at 12:37 AM, Sumedha Rubasinghe <[email protected]> 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 you read without a transaction block, you will get to see all committed > data in the database. Which is the correct representation. > Yes, this is correct. > > If you read within a transaction, you will also see uncommitted data > **within that transaction**. > This too is correct. But, there is another aspect. Since we have read-committed and row-locking, if you read and write at the same time to the same row, and the read is in a transaction, the write is blocked until that transaction is complete. In the link I shared for example, it is clearly explained. My understanding is that most DBs have this behavior. Correct me if I'm wrong here. > > But in our case, in most of the places where we read data, we should only > be seeing committed data. Thus no need to READ/SELECT with in a > transactional block. > The issue is in this assumption. When you read data in a single SELECT, you are guaranteed to read committed data. But, if you read data in multiple SELECTs, there is no such guarantee unless you are in a transaction. Only way to overcome the need for this transaction therefore is to create procedures for each and every DB we support, which has its own pros and cons, and also debatable issues when it comes to DBAs, which is IIRC, the main reason we gave up on that. So, if you want to ensure no data corruption during a read, AFAIU this approach is required isn't it? This is what I recall as why we decided to keep transactions for get() calls when this whole thing was introduced into the registry during the "you can corrupt registry by crashing the server during start-up" days. But, may be I'm missing something. Thanks, Senaka. > > > On Tue, Aug 19, 2014 at 4:06 AM, Senaka Fernando <[email protected]> wrote: > >> 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] >> http://stackoverflow.com/questions/1976686/is-there-a-difference-between-a-select-statement-inside-a-transaction-and-one-th >> >> Thanks, >> Senaka. >> >> >> On Mon, Aug 18, 2014 at 11:29 PM, Sumedha Rubasinghe <[email protected]> >> wrote: >> >>> 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 >>> uncommitted data. >>> >>> But we use neither of these scenarios. So I believe there is not need to >>> read within transaction blocks. >>> >>> >>> >>> >>> On Tue, Aug 19, 2014 at 3:49 AM, Senaka Fernando <[email protected]> >>> wrote: >>> >>>> 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 transactional. >>>> >>>> But, I was under the impression that the cache solves this issue >>>> altogether with the get() doing nothing @ Embedded Registry level. Isn't >>>> this the case or are you talking about first call slow-down? >>>> >>>> Thanks, >>>> Senaka. >>>> >>>> >>>> On Mon, Aug 18, 2014 at 6:36 AM, Subash Chaturanga <[email protected]> >>>> wrote: >>>> >>>>> 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 EmbeddedRegitry#get. >>>>> >>>>> -- >>>>> Thanks >>>>> /subash >>>>> >>>>> *Subash Chaturanga* >>>>> Senior Software Engineer & Lead WSO2 Governance Registry >>>>> Platform TG; WSO2 Inc. http://wso2.com >>>>> Contact: >>>>> email: [email protected] >>>>> blog: http://subashsdm.blogspot.com/ >>>>> twitter: @subash89 >>>>> phone: +9477 2225922 >>>>> Lean . Enterprise . Middleware >>>>> >>>> >>>> >>>> >>>> -- >>>> >>>> >>>> *[image: http://wso2.com] <http://wso2.com> Senaka Fernando* >>>> Software Architect; WSO2 Inc.; http://wso2.com >>>> >>>> >>>> >>>> * Member; Apache Software Foundation; http://apache.org >>>> <http://apache.org>E-mail: senaka AT wso2.com <http://wso2.com>**P: +1 >>>> 408 754 7388 <%2B1%20408%20754%207388>; ext: 51736*; >>>> >>>> >>>> *M: +44 782 741 1966 <%2B44%20782%20741%201966> Linked-In: >>>> http://linkedin.com/in/senakafernando >>>> <http://linkedin.com/in/senakafernando>* >>>> Lean . Enterprise . Middleware >>>> >>> >>> >>> >>> -- >>> /sumedha >>> m: +94 773017743 >>> b : bit.ly/sumedha >>> >> >> >> >> -- >> >> >> *[image: http://wso2.com] <http://wso2.com> Senaka Fernando* >> Software Architect; WSO2 Inc.; http://wso2.com >> >> >> >> * Member; Apache Software Foundation; http://apache.org >> <http://apache.org>E-mail: senaka AT wso2.com <http://wso2.com>**P: +1 >> 408 754 7388 <%2B1%20408%20754%207388>; ext: 51736*; >> >> >> *M: +44 782 741 1966 <%2B44%20782%20741%201966> Linked-In: >> http://linkedin.com/in/senakafernando >> <http://linkedin.com/in/senakafernando>*Lean . Enterprise . Middleware >> > > > > -- > /sumedha > m: +94 773017743 > b : bit.ly/sumedha > -- *[image: http://wso2.com] <http://wso2.com> Senaka Fernando* Software Architect; WSO2 Inc.; http://wso2.com * Member; Apache Software Foundation; http://apache.org <http://apache.org>E-mail: senaka AT wso2.com <http://wso2.com>**P: +1 408 754 7388; ext: 51736*; *M: +44 782 741 1966 Linked-In: http://linkedin.com/in/senakafernando <http://linkedin.com/in/senakafernando>*Lean . Enterprise . Middleware
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
