Hello all,
I am making several web sites, which all have their own way to present underlying objects. So something like (in a concise format, something like python): Class RealUnit: quantity Class MySite: myItems Class SiteUnit: realUnit So sites all have a collection of site units, and site units are one-to-one with real units, they simply present a different perspective of that same unit. SiteUnit is just a presentation, it has no quantity, only real units do. So my question is, if two sites try to decrease the quantity of the underlying real unit does that have to be protected by a mutex or something? I would expect so, but perhaps Seaside already protects access to all object access somehow? Thanks, Jason _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
2007/10/10, Jason Johnson <[hidden email]>:
> Hello all, > > I am making several web sites, which all have their own way to present > underlying objects. So something like (in a concise format, something > like python): > > Class RealUnit: > quantity > Class MySite: > myItems > Class SiteUnit: > realUnit > > So sites all have a collection of site units, and site units are > one-to-one with real units, they simply present a different perspective > of that same unit. SiteUnit is just a presentation, it has no quantity, > only real units do. So my question is, if two sites try to decrease the > quantity of the underlying real unit does that have to be protected by a > mutex or something? Sure. Have a look at the latest patches from Andres. These put semaphores in a "semms to work" state. > I would expect so, but perhaps Seaside already protects access to all > object access somehow? How would Seaside know about your objects? Seaside only knows about its own objects. Cheers Philippe > Thanks, > Jason > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Hi Jason,
Be sure to look at SharedQueue. You can have seaside put an update request into the queue and then have a separate process pull from that queue and update your objects. This will open a bit of a window for stale data, but if your application has a low threshold requiring data accuracy this is a good way to go. This actually gets easier if you add a DB. You can have a process pulling from a queue table, to update your object, and then you can easily support multiple running images. But once again you have a stale data issue. If you must have an accurate answer then you need to lock the shared objects for read and write. (or handle exceptions on write if value changes) Happy Coding, Ron Teitelbaum President / Principal Software Engineer US Medical Record Specialists > From: Philippe Marschall > > 2007/10/10, Jason Johnson <[hidden email]>: > > Hello all, > > > > I am making several web sites, which all have their own way to present > > underlying objects. So something like (in a concise format, something > > like python): > > > > Class RealUnit: > > quantity > > Class MySite: > > myItems > > Class SiteUnit: > > realUnit > > > > So sites all have a collection of site units, and site units are > > one-to-one with real units, they simply present a different perspective > > of that same unit. SiteUnit is just a presentation, it has no quantity, > > only real units do. So my question is, if two sites try to decrease the > > quantity of the underlying real unit does that have to be protected by a > > mutex or something? > > Sure. Have a look at the latest patches from Andres. These put > semaphores in a "semms to work" state. > > > I would expect so, but perhaps Seaside already protects access to all > > object access somehow? > > How would Seaside know about your objects? Seaside only knows about > its own objects. > > Cheers > Philippe > > > Thanks, > > Jason _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Philippe Marschall
Philippe Marschall wrote:
> Sure. Have a look at the latest patches from Andres. These put > semaphores in a "semms to work" state. > Hrm. If I have to guard my own memory I might try something else (e.g. message passing). > How would Seaside know about your objects? Seaside only knows about > its own objects. > > Cheers > Philippe Ok, I just never see people talk about this, so I thought maybe Seaside was doing something for it some how. _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Ron Teitelbaum
Ron Teitelbaum wrote:
> Hi Jason, > > Be sure to look at SharedQueue. You can have seaside put an update request > into the queue and then have a separate process pull from that queue and > update your objects. This will open a bit of a window for stale data, but > if your application has a low threshold requiring data accuracy this is a > good way to go. > Ok, I'll have to look at that. At that point, I would be conceptually a bit like an Erlang process. > This actually gets easier if you add a DB. You can have a process pulling > from a queue table, to update your object, and then you can easily support > multiple running images. But once again you have a stale data issue. > This is also a good idea. Anyone know how heavy magma is? I think an OODB would be the least impacting thing to use here, and is probably a good idea anyway since I'll need persistence. > If you must have an accurate answer then you need to lock the shared objects > for read and write. (or handle exceptions on write if value changes) > > Happy Coding, > > Ron Teitelbaum > President / Principal Software Engineer > US Medical Record Specialists Ugh, there must be another way to achieve accuracy. _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Free forum by Nabble | Edit this page |