Deployment pharo with multiple instances and voyage
Hi! Iâm close to deploy a web service using Pharo with Voyage and MongoDB. I have been playing with it and everything works ok with a single Pharo image. Couple of days ago I started questioning myself about how voyage behaves when you have multiple pharo images using the same mongo database (horizontal scaling). I want to know how the cache of voyage behaves in a scenario with object updates. Example: ââââââââââââââ Imagine I have two images A and B. - Image A query for object o and voyage put it in the cache. - Image B query for object o and voyage put it in the cache. - Image A updates object o and push it into the database calling #save. - Image B query for object o that should be already in the cache. In this case, does Image B see the changes performed by image A? ââââââââââââââ All ideas are welcome :) Thanks and cheers! Alejandro
Hi,
Am 25.01.2017 um 01:30 schrieb Alejandro Infante <alejandroinfante91@gmail.com>:
Hi!
Iâm close to deploy a web service using Pharo with Voyage and MongoDB. I have been playing with it and everything works ok with a single Pharo image.
Couple of days ago I started questioning myself about how voyage behaves when you have multiple pharo images using the same mongo database (horizontal scaling). I want to know how the cache of voyage behaves in a scenario with object updates.
Example: ââââââââââââââ Imagine I have two images A and B.
- Image A query for object o and voyage put it in the cache. - Image B query for object o and voyage put it in the cache. - Image A updates object o and push it into the database calling #save. - Image B query for object o that should be already in the cache.
In this case, does Image B see the changes performed by image A? ââââââââââââââ
All ideas are welcome :)
the only problems you have with the cache is its name :) It isn't really a cache. If you request an object a query is issued to the database. So your scenario is no problem because in the last step when B queries the object it queries the database, will see that the version number of the objects changed and will update the object in the cache. The sole purpose of the cache is to enable identity of database objects. Nevertheless you can have problems if you use references. Voyage can handle references pretty well. But each class might be stored in another document/collection. As in mongo only the storage of a single document is atomic you need to be careful when doing concurrent updates with references. Norbert
On 25 Jan 2017, at 01:30, Alejandro Infante <alejandroinfante91@gmail.com> wrote:
Hi!
Iâm close to deploy a web service using Pharo with Voyage and MongoDB. I have been playing with it and everything works ok with a single Pharo image.
Couple of days ago I started questioning myself about how voyage behaves when you have multiple pharo images using the same mongo database (horizontal scaling). I want to know how the cache of voyage behaves in a scenario with object updates.
Example: ââââââââââââââ Imagine I have two images A and B.
- Image A query for object o and voyage put it in the cache. - Image B query for object o and voyage put it in the cache. - Image A updates object o and push it into the database calling #save. - Image B query for object o that should be already in the cache.
In this case, does Image B see the changes performed by image A? ââââââââââââââ
yes. Voyage will always verify the version on the mongodb, no matter the cache, because in fact, the cache of Voyage is meant just to keep object identity (there has been discussions on if this is a real cache⦠I think it is, but with a different purpose than usual). Recently Martin enhanced that part by adding VMMongoRepository>>saveEnsuringCurrent: protocol who will also check your version is correct when writing (to avoid overwrite before update). So, this should be Ok :) Esteban
All ideas are welcome :)
Thanks and cheers! Alejandro
Cool! Thanks for the answers! Norbert mentions something interesting about references. I have found that even though on each query mongo get the up-to-date version of the objects, it does not install the proxies to look for the up-to-date versions of the references of the queried object. I made the following experiment: Having two images 1 and 2 and two classes A and B, each of them having one instance variable. âââââââââ Image 1 (Create two objects, âaâ referencing âbâ) [ |a b| a := A new. b := B new a setInstVar: b. b setInstVar: âfoo'. b save. a save. ] Image 2 (Mutates the second object, but the first is not changed) [ b := (repository selectAll: A) first instVar. b setInstVar: âbarâ. b save. ] Image 1 (Query the first object and access to the referenced object) [ b := (repository selectAll: A) first instVar. b instVar. â-> fooâ b := (repository selectAll: B) first. b instVar. â-> bar" ] This little experiment showed me that I cannot trust on the state of other objects that I have not explicitly queried for. Is there any way of solving this without creating new instances of voyage repositories for each request? Thanks! Alejandro
On Jan 25, 2017, at 7:27 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 25 Jan 2017, at 01:30, Alejandro Infante <alejandroinfante91@gmail.com> wrote:
Hi!
Iâm close to deploy a web service using Pharo with Voyage and MongoDB. I have been playing with it and everything works ok with a single Pharo image.
Couple of days ago I started questioning myself about how voyage behaves when you have multiple pharo images using the same mongo database (horizontal scaling). I want to know how the cache of voyage behaves in a scenario with object updates.
Example: ââââââââââââââ Imagine I have two images A and B.
- Image A query for object o and voyage put it in the cache. - Image B query for object o and voyage put it in the cache. - Image A updates object o and push it into the database calling #save. - Image B query for object o that should be already in the cache.
In this case, does Image B see the changes performed by image A? ââââââââââââââ
yes. Voyage will always verify the version on the mongodb, no matter the cache, because in fact, the cache of Voyage is meant just to keep object identity (there has been discussions on if this is a real cache⦠I think it is, but with a different purpose than usual). Recently Martin enhanced that part by adding VMMongoRepository>>saveEnsuringCurrent: protocol who will also check your version is correct when writing (to avoid overwrite before update).
So, this should be Ok :)
Esteban
All ideas are welcome :)
Thanks and cheers! Alejandro
On 25 Jan 2017, at 22:39 , Alejandro Infante <alejandroinfante91@gmail.com> wrote:
Cool! Thanks for the answers!
Norbert mentions something interesting about references. I have found that even though on each query mongo get the up-to-date version of the objects, it does not install the proxies to look for the up-to-date versions of the references of the queried object.
I made the following experiment: Having two images 1 and 2 and two classes A and B, each of them having one instance variable. âââââââââ Image 1 (Create two objects, âaâ referencing âbâ) [ |a b| a := A new. b := B new a setInstVar: b. b setInstVar: âfoo'. b save. a save. ]
Image 2 (Mutates the second object, but the first is not changed) [ b := (repository selectAll: A) first instVar. b setInstVar: âbarâ. b save. ]
Image 1 (Query the first object and access to the referenced object) [ b := (repository selectAll: A) first instVar. b instVar. â-> fooâ b := (repository selectAll: B) first. b instVar. â-> bar" ]
This little experiment showed me that I cannot trust on the state of other objects that I have not explicitly queried for.
Is there any way of solving this without creating new instances of voyage repositories for each request?
Thanks! Alejandro
Three, actually ;) - Accept that an image will contain some stale values, and deal with conflicts at save time. This is the most performant/scalable. - Always save only root objects More overhead since there's more likeliness of cache misses and actual reloads, but you can be sure any query will return the freshest value. - Extend retrieveObjectOf:json: to either replace doc refs with proxies, or do eager (recursive) lookup of whether cached versions of referenced documents are up-to-date when returning a cached object. In reality, only the first really makes sense; as you can never guarantee how long a queried object stays current. Cheers, Henry
This is great I would love to know what is your application and we should add it in the success stories. Stef
Hi!
Iâm close to deploy a web service using Pharo with Voyage and MongoDB. I have been playing with it and everything works ok with a single Pharo image.
Couple of days ago I started questioning myself about how voyage behaves when you have multiple pharo images using the same mongo database (horizontal scaling). I want to know how the cache of voyage behaves in a scenario with object updates.
Example: ââââââââââââââ Imagine I have two images A and B.
- Image A query for object o and voyage put it in the cache. - Image B query for object o and voyage put it in the cache. - Image A updates object o and push it into the database calling #save. - Image B query for object o that should be already in the cache.
In this case, does Image B see the changes performed by image A? ââââââââââââââ
All ideas are welcome :)
Thanks and cheers! Alejandro
-- Using Opera's mail client: http://www.opera.com/mail/
+1
Le 26 janv. 2017 à 16:10, stepharong <stepharong@free.fr> a écrit :
This is great I would love to know what is your application and we should add it in the success stories.
Stef
Hi!
Iâm close to deploy a web service using Pharo with Voyage and MongoDB. I have been playing with it and everything works ok with a single Pharo image.
Couple of days ago I started questioning myself about how voyage behaves when you have multiple pharo images using the same mongo database (horizontal scaling). I want to know how the cache of voyage behaves in a scenario with object updates.
Example: ââââââââââââââ Imagine I have two images A and B.
- Image A query for object o and voyage put it in the cache. - Image B query for object o and voyage put it in the cache. - Image A updates object o and push it into the database calling #save. - Image B query for object o that should be already in the cache.
In this case, does Image B see the changes performed by image A? ââââââââââââââ
All ideas are welcome :)
Thanks and cheers! Alejandro
-- Using Opera's mail client: http://www.opera.com/mail/
participants (6)
-
Alejandro Infante -
Alexandre Bergel -
Esteban Lorenzano -
Henrik Johansen -
Norbert Hartl -
stepharong