Alberto
> Alberto,
>
> I am asking about that for years. Just some promises.
> Still no luck. Oracle has it 20 years, Microsoft already 3
> years. Probably they are waiting for IBM which also does
> not have it so far AFAIK. I think without that it is not
> even truly relational database.
>
> Regards,
> Eugene
> Alberto da Silva wrote:
>
> >Multiversion concurrency control
> >http://en.wikipedia.org/wiki/Multiversion_concurrency_con
> trol >Does anyone know if ASE will get this feature?
what a coincidence! I was about to submit the feature request on ISUG site.
If you are ISUG members, please vote for it.
Regards
Niksa Jurinovic
ni...@jurinovic.de
"Eugene Korolkov" <ekor...@davidsohn.com> wrote in message news:486D344F...@davidsohn.com...
It may be a very good feature to have but "I think without that it is not even truly relational database" is a really foolish statement. One could claim that a DBMS isn't relational unless is it is column-based or must support both datapage and datarow locking just as well with that "logic".
> It may be a very good feature to have but "I think without that it is
> not even truly relational database" is a really foolish statement. One
> could claim that a DBMS isn't relational unless is it is column-based or
> must support both datapage and datarow locking just as well with that
> "logic".
Hi Carl,
even though the definition of "RELATIONAL DBMS" has nothing to do with the
definition of "MULTIVERSION CONCURRENCY" (many users can access data at the
same time) or "MULTIVERSION CONSISTENCY" (each user sees a consistent view
of the data), they are closely tied up together, particularly in practice.
So, I don't think Eugene's statement is foolish. It may be called a "syntax
error", but semantically it holds water.
Anyway I submitted the ISUG feature request yesterday and, in a week or so,
hope it will be in. I expect you'll vote positive. It's high time ASE
product management folks adopted this technology, since their current
locking schema is horrific. Even dirty reads had to be allowed to bypass
the limitation of such a technology (unwanted blockings and waitings).
Personally, I'd be happy to see a model similar to Oracle's. Oracle
combines multiversion concurrency control with non-escalating row-level
locking. This is a very efficient, flexible and logically consistent
transaction model which guarantees that
* readers never block writers
* writers never block readers
* different-row writers never block writers
This is true at statement-level and transaction-level, either by READ
COMMITTED or SERIALIZABLE isolation level. Only same-row writers block
writers, that is normal. Each user is guaranteed to see a consistent view
(snapshot) of the data that was committed at the time the query started.
Since allowing dirty reads doesn't make any sense in the model (no
lockings/blockings having to be bypassed), the READ UNCOMMITTED isolation
level doesn't exist. This is a must-have technology for any serious DBMS,
relational or non-relational. Hope we are agreed on this.
Regards
Niksa Jurinovic
ni...@jurinovic.de
Am a member of ISUG and will vote for the request.
From my understanding, backupserver seems to use MVCC.
Regards,
Alberto
The backup server result (dbump) is like select under snapshot isolation,
but taking at the end of select, not at the beginning which is usual for
that,
though it is not using sql at all I think, just straight OS copy + applying
trlog changes.
I even proposed for ASE 2 forms of the select cmd result:
(1st-the snapshot taking before select starts i.e. ignoring any changes
(updates/inserts,deletes)
happened during select execution) , 2nd -after it is finished, i.e. with all
changes have been applied.
(like backupserver dump)
Actually Oracle already has flashback queries, i.e. select result with
changes at any time back.
Regards,
Eugene
<Alberto da Silva> wrote in message
news:4871e119.249...@sybase.com...