[morphia] feat-req: optimistic locking
6 views
Skip to first unread message
Uwe Schäfer
May 9, 2010, 2:34:48 PM5/9/10
to mor...@googlegroups.com
Hi
i´d like to hear the list´s option about the integration of
optimistic locking
>> - versioning and optimistic locking
> I assume the
> locking you are thinking of would be related to incrementally
> increasing object versions (on saves).
exactly. that would mean, that before passing the document to mongo, the
version number should be re-requested to see if it still matches the
expect one, or a conflicting change has happened.
as i am a complete rookie when it comes to mongo: is it possible to lock
that document in between?
as this probably increases chatty-ness of morphia, this should be
restricted to entities requesting this:
class Foo implements Versioned
{
// ...
}
interface Versioned{
long getVersion();
void setVersion(long version);
}
agree?
> There is also the issue of
> having different version of you classes, in terms of migrating data
> from one version to another (where there might be many versions of
> data stored in mongodb). For that one we have a few features which
> will help.
that would be evolving classes, which should (and do) have a version as
well (serialVersionUID).
did not look into this, yet.
cu uwe
i´d like to hear the list´s option about the integration of
optimistic locking
>> - versioning and optimistic locking
> I assume the
> locking you are thinking of would be related to incrementally
> increasing object versions (on saves).
exactly. that would mean, that before passing the document to mongo, the
version number should be re-requested to see if it still matches the
expect one, or a conflicting change has happened.
as i am a complete rookie when it comes to mongo: is it possible to lock
that document in between?
as this probably increases chatty-ness of morphia, this should be
restricted to entities requesting this:
class Foo implements Versioned
{
// ...
}
interface Versioned{
long getVersion();
void setVersion(long version);
}
agree?
> There is also the issue of
> having different version of you classes, in terms of migrating data
> from one version to another (where there might be many versions of
> data stored in mongodb). For that one we have a few features which
> will help.
that would be evolving classes, which should (and do) have a version as
well (serialVersionUID).
did not look into this, yet.
cu uwe
Scott Hernandez
May 9, 2010, 4:54:33 PM5/9/10
to mor...@googlegroups.com
2010/5/9 Uwe Schäfer <u...@thomas-daily.de>:
We could probably do something with an update by specifying the _id +
version as a key (http://www.mongodb.org/display/DOCS/Updating) marked
as non-inserting. We can then check the result; if the update worked
then the version was correct, if not throw an exception. The update
will be atomic.
> as this probably increases chatty-ness of morphia, this should be restricted
> to entities requesting this:
>
> class Foo implements Versioned
> {
> // ...
> }
> interface Versioned{
> long getVersion();
> void setVersion(long version);
> }
>
> agree?
Looks good but I dislike requiring interfaces. The JPA style
annotation fits with what we have now. @Versioned must be a long.
>> There is also the issue of
>> having different version of you classes, in terms of migrating data
>> from one version to another (where there might be many versions of
>> data stored in mongodb). For that one we have a few features which
>> will help.
>
> that would be evolving classes, which should (and do) have a version as well
> (serialVersionUID).
serialization and persistence are not the same thing :(
> did not look into this, yet.
Take a look at how we do it in Objectify
(http://code.google.com/p/objectify-appengine/wiki/IntroductionToObjectify#Migrating_Schemas)
It works well for live systems with various version of saved entities.
> cu uwe
>
> Hi
>
> i´d like to hear the list´s option about the integration of
> optimistic locking
>
>>> - versioning and optimistic locking
>> I assume the
>> locking you are thinking of would be related to incrementally
>> increasing object versions (on saves).
>
> exactly. that would mean, that before passing the document to mongo, the
> version number should be re-requested to see if it still matches the expect
> one, or a conflicting change has happened.
>
> as i am a complete rookie when it comes to mongo: is it possible to lock
> that document in between?
Nope, no transactions in mongo. It would have to be done in morphia.
>
> i´d like to hear the list´s option about the integration of
> optimistic locking
>
>>> - versioning and optimistic locking
>> I assume the
>> locking you are thinking of would be related to incrementally
>> increasing object versions (on saves).
>
> exactly. that would mean, that before passing the document to mongo, the
> version number should be re-requested to see if it still matches the expect
> one, or a conflicting change has happened.
>
> as i am a complete rookie when it comes to mongo: is it possible to lock
> that document in between?
We could probably do something with an update by specifying the _id +
version as a key (http://www.mongodb.org/display/DOCS/Updating) marked
as non-inserting. We can then check the result; if the update worked
then the version was correct, if not throw an exception. The update
will be atomic.
> as this probably increases chatty-ness of morphia, this should be restricted
> to entities requesting this:
>
> class Foo implements Versioned
> {
> // ...
> }
> interface Versioned{
> long getVersion();
> void setVersion(long version);
> }
>
> agree?
annotation fits with what we have now. @Versioned must be a long.
>> There is also the issue of
>> having different version of you classes, in terms of migrating data
>> from one version to another (where there might be many versions of
>> data stored in mongodb). For that one we have a few features which
>> will help.
>
> that would be evolving classes, which should (and do) have a version as well
> (serialVersionUID).
> did not look into this, yet.
(http://code.google.com/p/objectify-appengine/wiki/IntroductionToObjectify#Migrating_Schemas)
It works well for live systems with various version of saved entities.
> cu uwe
>
Ólafur Gauti Guðmundsson
May 10, 2010, 6:31:06 AM5/10/10
to Morphia
Versioning would be a great feature to support, as it is one required
by many enterprise systems. However, it quickly becomes a complex
subject. Ideally, it is something that I would like to have
implemented in Mongo (something like a versioned collection).
I assume you need to maintain a version history. This means that you
can browse all versions of the content, to see what has changed. Allow
rolling back to a previous state, merging, etc.
You would normally need more than just the version number (person
making the change, date the change was made, etc.), but that could be
implemented on the application level.
But you would also need something linking a set of versions together.
Would there be a parent object for the Version list, or could this be
implemented by having an @Embedded version list?
Maybe versioning is something that the Mongo people intend to
implement. Need to check that.
Cheers,
OGG
by many enterprise systems. However, it quickly becomes a complex
subject. Ideally, it is something that I would like to have
implemented in Mongo (something like a versioned collection).
I assume you need to maintain a version history. This means that you
can browse all versions of the content, to see what has changed. Allow
rolling back to a previous state, merging, etc.
You would normally need more than just the version number (person
making the change, date the change was made, etc.), but that could be
implemented on the application level.
But you would also need something linking a set of versions together.
Would there be a parent object for the Version list, or could this be
implemented by having an @Embedded version list?
Maybe versioning is something that the Mongo people intend to
implement. Need to check that.
Cheers,
OGG
Scott Hernandez
May 10, 2010, 11:39:27 AM5/10/10
to mor...@googlegroups.com
2010/5/10 Ólafur Gauti Guðmundsson <oli....@gmail.com>:
version(ed/ing). One is support for something like JPA's @Versioned,
where if you have an old instance of the object you will get an error
if you try to save it. Two is keeping a history of all changes (so
that you have many versions of you entity stored), and the third
revolves around around the issues of loading different versions (note,
there is only one stored instance of your entity, but it might have
been stored by an old version of your entity class -- like before you
added a field, or renamed one) of you entities from the datastore. The
third is more about migrating schema changes and loading that data
from newer instances (assuming you don't need to run old versions of
your application at the same time). Some people call this a "live
upgrade" where you deploy a new version of your application (where you
have changed the schema -- class files -- in an incompatible ) but
don't want to reprocess all stored instanced before the deployment.
Live upgrades allow for no downtime, but may require more code to
support intermediate or transitional data loading and schema changes.
The idea of this feature is for the first case (@Versioned JPA-style).
I think we can do this efficiently using updates with a filter on the
current version. This feature is especially important for GWT and
places where you serialize your entities over a matter of seconds or
minutes, or more. It will catch the "someone else edited it first"
problem.
> I assume you need to maintain a version history. This means that you
> can browse all versions of the content, to see what has changed. Allow
> rolling back to a previous state, merging, etc.
>
> You would normally need more than just the version number (person
> making the change, date the change was made, etc.), but that could be
> implemented on the application level.
>
> But you would also need something linking a set of versions together.
> Would there be a parent object for the Version list, or could this be
> implemented by having an @Embedded version list?
>
> Maybe versioning is something that the Mongo people intend to
> implement. Need to check that.
I don't think anyone has asked for versioning support. I have a simple
change-log that I do based on the prePersist lifecycle event in each
of my entities which I want to track. I just inspect each field and
for one that has changed I create a new EntityChanged(who, field, old,
new) object, and then I save them.
> Versioning would be a great feature to support, as it is one required
> by many enterprise systems. However, it quickly becomes a complex
> subject. Ideally, it is something that I would like to have
> implemented in Mongo (something like a versioned collection).
There are 3 things that come up when we talk about some kind of
> by many enterprise systems. However, it quickly becomes a complex
> subject. Ideally, it is something that I would like to have
> implemented in Mongo (something like a versioned collection).
version(ed/ing). One is support for something like JPA's @Versioned,
where if you have an old instance of the object you will get an error
if you try to save it. Two is keeping a history of all changes (so
that you have many versions of you entity stored), and the third
revolves around around the issues of loading different versions (note,
there is only one stored instance of your entity, but it might have
been stored by an old version of your entity class -- like before you
added a field, or renamed one) of you entities from the datastore. The
third is more about migrating schema changes and loading that data
from newer instances (assuming you don't need to run old versions of
your application at the same time). Some people call this a "live
upgrade" where you deploy a new version of your application (where you
have changed the schema -- class files -- in an incompatible ) but
don't want to reprocess all stored instanced before the deployment.
Live upgrades allow for no downtime, but may require more code to
support intermediate or transitional data loading and schema changes.
The idea of this feature is for the first case (@Versioned JPA-style).
I think we can do this efficiently using updates with a filter on the
current version. This feature is especially important for GWT and
places where you serialize your entities over a matter of seconds or
minutes, or more. It will catch the "someone else edited it first"
problem.
> I assume you need to maintain a version history. This means that you
> can browse all versions of the content, to see what has changed. Allow
> rolling back to a previous state, merging, etc.
>
> You would normally need more than just the version number (person
> making the change, date the change was made, etc.), but that could be
> implemented on the application level.
>
> But you would also need something linking a set of versions together.
> Would there be a parent object for the Version list, or could this be
> implemented by having an @Embedded version list?
>
> Maybe versioning is something that the Mongo people intend to
> implement. Need to check that.
change-log that I do based on the prePersist lifecycle event in each
of my entities which I want to track. I just inspect each field and
for one that has changed I create a new EntityChanged(who, field, old,
new) object, and then I save them.
Uwe Schäfer
May 10, 2010, 11:50:20 AM5/10/10
to mor...@googlegroups.com
Ólafur Gauti Guðmundsson schrieb:#
Hi Ólafur
> Versioning would be a great feature to support, as it is one required
> by many enterprise systems. However, it quickly becomes a complex
> subject. Ideally, it is something that I would like to have
> implemented in Mongo (something like a versioned collection).
agreed. Looking at hibernate Envers, it looks possible (though without
any doubt complex) to do it in the mapping layer.
however, that´s far beyond what i meant to request.
i did not think of versions within mongo, but just a *version number* in
every entity, that can be used to detect (thus avoid) concurrent updates.
that would just mean to compare and increase a documents version on
save, and deny saving it if the version number is not as expected.
nothing more. same pattern than JPA has, actually.
the "update by id & version" idea of scott´s looks great here.
cu uwe
--
THOMAS DAILY GmbH
Adlerstraße 19
79098 Freiburg
Deutschland
T + 49 761 3 85 59 0
F + 49 761 3 85 59 550
E scha...@thomas-daily.de
www.thomas-daily.de
Geschäftsführer/Managing Directors:
Wendy Thomas, Susanne Larbig
Handelsregister Freiburg i.Br., HRB 3947
Registrieren Sie sich unter https://www.thomas-daily.de/user/sign-in für
die TD Morning News, eine kostenlose Auswahl aktueller Themen aus TD
Premium, morgens ab 9:15 in Ihrer Mailbox.
Aktuelle Presseinformationen für die TD Morning News und TD Premium
nimmt unsere Redaktion unter reda...@thomas-daily.de entgegen.
Redaktionsschluss für die TD Morning News ist täglich um 8:45.
Register free of charge at https://www.thomas-daily.de/user/sign-in to
have the TD Morning News, a selection of the latest topics from TD
Premium, delivered to your mailbox from 9:15 every morning.
Our editorial department receives the latest press releases for the TD
Morning News and TD Premium at reda...@thomas-daily.de. The editorial
deadline for the TD Morning News is 8.45am daily.
Hi Ólafur
> Versioning would be a great feature to support, as it is one required
> by many enterprise systems. However, it quickly becomes a complex
> subject. Ideally, it is something that I would like to have
> implemented in Mongo (something like a versioned collection).
any doubt complex) to do it in the mapping layer.
however, that´s far beyond what i meant to request.
i did not think of versions within mongo, but just a *version number* in
every entity, that can be used to detect (thus avoid) concurrent updates.
that would just mean to compare and increase a documents version on
save, and deny saving it if the version number is not as expected.
nothing more. same pattern than JPA has, actually.
the "update by id & version" idea of scott´s looks great here.
cu uwe
--
THOMAS DAILY GmbH
Adlerstraße 19
79098 Freiburg
Deutschland
T + 49 761 3 85 59 0
F + 49 761 3 85 59 550
E scha...@thomas-daily.de
www.thomas-daily.de
Geschäftsführer/Managing Directors:
Wendy Thomas, Susanne Larbig
Handelsregister Freiburg i.Br., HRB 3947
Registrieren Sie sich unter https://www.thomas-daily.de/user/sign-in für
die TD Morning News, eine kostenlose Auswahl aktueller Themen aus TD
Premium, morgens ab 9:15 in Ihrer Mailbox.
Aktuelle Presseinformationen für die TD Morning News und TD Premium
nimmt unsere Redaktion unter reda...@thomas-daily.de entgegen.
Redaktionsschluss für die TD Morning News ist täglich um 8:45.
Register free of charge at https://www.thomas-daily.de/user/sign-in to
have the TD Morning News, a selection of the latest topics from TD
Premium, delivered to your mailbox from 9:15 every morning.
Our editorial department receives the latest press releases for the TD
Morning News and TD Premium at reda...@thomas-daily.de. The editorial
deadline for the TD Morning News is 8.45am daily.
Uwe Schäfer
May 10, 2010, 11:50:33 AM5/10/10
to mor...@googlegroups.com
Scott Hernandez schrieb:
Dear Scott,
> One is support for something like JPA's @Versioned,
> where if you have an old instance of the object you will get an error
> if you try to save it.
+1 :)
> I have a simple
> change-log that I do based on the prePersist lifecycle event in each
> of my entities which I want to track. I just inspect each field and
> for one that has changed I create a new EntityChanged(who, field, old,
> new) object, and then I save them.
so did i (in JPA) - fairly sufficient.
thanks for clearing that up.
cu uwe
Dear Scott,
> One is support for something like JPA's @Versioned,
> where if you have an old instance of the object you will get an error
> if you try to save it.
> I have a simple
> change-log that I do based on the prePersist lifecycle event in each
> of my entities which I want to track. I just inspect each field and
> for one that has changed I create a new EntityChanged(who, field, old,
> new) object, and then I save them.
thanks for clearing that up.
cu uwe
Reply all
Reply to author
Forward
0 new messages