Question about access to a shared object

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Question about access to a shared object

Jason Johnson-3
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
Reply | Threaded
Open this post in threaded view
|

Re: Question about access to a shared object

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
>
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

RE: Question about access to a shared object

Ron Teitelbaum
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
Reply | Threaded
Open this post in threaded view
|

Re: Question about access to a shared object

Jason Johnson-3
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
Reply | Threaded
Open this post in threaded view
|

Re: Question about access to a shared object

Jason Johnson-3
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