Hi,
in OrientDB all operations against records are atomic. The problem on SQL
UPDATE is that during the time the record is extracted and updated, on
high-concurrency environment, another thread/client could change it. So in
this case the record should be locked on select to avoid such behavior or,
at least, an auto-retry should be provided.

This is the reason for new keyword to control concurrency like posted on:
https://groups.google.com/d/msg/orient-database/fD-UNnq9zmc/lz0j4T8Pi-gJ

Lvc@



On 3 January 2014 21:49, Andrey Lomakin <[email protected]> wrote:

> Hi,
> Currently operations on single document are atomic.  I asked question
> about increment because some times phrase "atomic operations" is used in
> sense "operations without cme".
>
> 03.01.2014 21:32 пользователь "Pawel K." <[email protected]> написал:
>
> >
> > Andrey,
> > You said:"You provided example with  INCREMENT so I thought that may be
> you want to increment field without throwing CME, by simple addition of
> value to latest field value."
> > Actually right now, innocent at first look one-document sql update like
> >    Update #21:1 INCREMENT quantity = 100
> > generates CME.
> > I discuessed similar scenario with Luca at this issue:
> >
> > https://github.com/orientechnologies/orientdb/issues/1834
> >
> > My understanding is similar to MongoDB doc which says
> >
> > "Write operations are atomic on the level of a single document: no
> single write operation can atomically affect more than one document or more
> than one collection.When a single write operation modifies multiple
> documents, the operation as a whole is not atomic, and other operations may
> interleave. The modification of a single document, or record, is always
> atomic, even if the write operation modifies multiple
> sub-document within the single record."
> http://docs.mongodb.org/manual/tutorial/isolate-sequence-of-operations/
> >
> > Without it CME has tremendous cost for business application
> (non-enmbedded db) and a little (desired) impact for database server
> performance (I could point an example when the cost for server is also
> substantial).
> >
> > Best regards,
> > Pawel
> >
> >
> > On Friday, January 3, 2014 3:02:33 PM UTC+1, Andrey Lomakin wrote:
> >>
> >> All document changes are atomic.
> >>
> >> So if you save single document , changes either applied or not, you do
> not need transaction for this kind of behavior.
> >> It does not matter whether you use SQL or Java.
> >>
> >> You provided example with  INCREMENT so I thought that may be you want
> to increment field without throwing CME, by simple addition of value to
> latest field value.
> >> And if you catch ConcurentModificationException you should reload
> record and try again.
> >>
> >>
> >>
> >> On Fri, Jan 3, 2014 at 2:30 PM, Leng Sheng Hong <[email protected]>
> wrote:
> >>>
> >>> Does it mean that if I save() something without callInRecordLock (but
> i am using plocal).
> >>> I will have to do it in a transaction?
> >>> If i am saving 2 fields, using
> >>> doc.fields("title", "texthere");
> >>> doc.fields("quantity", doc.fields("quantity") + 100 )  //atomic
> >>> doc.save()
> >>>
> >>> I think it should be done in a transaction if concurrent modification
> exception occured, i will have to reload the document and try saving again?
> >>>
> >>> Is that the same behaviour to
> >>> Update MyTable INCREMENT quantity = 100, set title = "texthere" where
> @rid = #21:1
> >>>
> >>>
> >>> On Friday, 3 January 2014 20:14:29 UTC+8, Andrey Lomakin wrote:
> >>>>
> >>>> Hi,
> >>>> What do you mean when write about atomic ? increment without
> concurrent modification exception ?
> >>>> If you use embedded storage you can lock records on storage level ,
> and then release them.
> >>>>
> >>>> You may use
> com.orientechnologies.orient.core.storage.OStorage#callInRecordLock but
> please use it with care, to avoid deadlocks.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On Fri, Jan 3, 2014 at 12:48 PM, Leng Sheng Hong <[email protected]>
> wrote:
> >>>>>
> >>>>> How do you do a SQL like this in Java api for a document base DB?
> >>>>> Update MyTable INCREMENT quantity = 100 where @rid = #21:1
> >>>>>
> >>>>> I doubt setting fields and save() is actually atomic?
> >>>>> doc.fields("quantity", doc.fields("quantity") + 100 )
> >>>>> doc.save()
> >>>>>
> >>>>> --
> >>>>>
> >>>>> ---
> >>>>> You received this message because you are subscribed to the Google
> Groups "OrientDB" group.
> >>>>> To unsubscribe from this group and stop receiving emails from it,
> send an email to [email protected].
> >>>>>
> >>>>> For more options, visit https://groups.google.com/groups/opt_out.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Best regards,
> >>>> Andrey Lomakin.
> >>>>
> >>>> Orient Technologies
> >>>> the Company behind OrientDB
> >>>>
> >>> --
> >>>
> >>> ---
> >>> You received this message because you are subscribed to the Google
> Groups "OrientDB" group.
> >>> To unsubscribe from this group and stop receiving emails from it, send
> an email to [email protected].
> >>> For more options, visit https://groups.google.com/groups/opt_out.
> >>
> >>
> >>
> >>
> >> --
> >> Best regards,
> >> Andrey Lomakin.
> >>
> >> Orient Technologies
> >> the Company behind OrientDB
> >>
> > --
> >
> > ---
> > You received this message because you are subscribed to the Google
> Groups "OrientDB" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to [email protected].
> > For more options, visit https://groups.google.com/groups/opt_out.
>
>  --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "OrientDB" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to