copying objects between segements
Locked
copying objects between segements
 
|
As it is not possible to upgrade from seaside 2.8 to 3.0 I created a new user in gemstone. I boostrapped the image and installed seaside 3.0. This worked with some struggles but ok.
Now I have the problem how to copy the pier kernel from my 2.8 segment to the 3.0 segment. At first I thought I'm very clever and just copy the object PRKernel from one site to the other. For this I added the user of the seaside 2.8 installation to the group Publishers and put the PRKernel object there. With the user of the seaside 3.0 installation I picked it from there and added it to the PRKernel instances on this side. Then I thought a second time. Of course this does not work. Every object pointer including classes still points to the segment of the seaside 2.8. No gain here. I thought about things like deep copying the whole tree and using addNewVersion to change classes from one side to the other but every approach seems rather complex. The last thing I tried was using Sixx as usual. I used the Published dictionary to exchange the sixx string but wasn't successful. The deserialized kernel displayed garbled on the web page half of the html structure read in as string and the encoding was not correct. Before trying too much you probably have an idea what would be the best/coolest/easiest way to transfer a kernel from one user to another. Norbert |
Re: copying objects between segements
|
|
Norbert Hartl wrote:
> As it is not possible to upgrade from seaside 2.8 to 3.0 I created a > new user in gemstone. I boostrapped the image and installed seaside > 3.0. This worked with some struggles but ok. > > Now I have the problem how to copy the pier kernel from my 2.8 > segment to the 3.0 segment. At first I thought I'm very clever and > just copy the object PRKernel from one site to the other. For this I > added the user of the seaside 2.8 installation to the group > Publishers and put the PRKernel object there. With the user of the > seaside 3.0 installation I picked it from there and added it to the > PRKernel instances on this side. Then I thought a second time. Of > course this does not work. Every object pointer including classes > still points to the segment of the seaside 2.8. No gain here. One thing about Segments ... object don't physically reside in a segment (yes the name is _very_ misleading and we will be changing the name in GemStone 3.0). A segment defines permissions at the object level, so an object in segment X actually just references segment X and the system uses the segment to identify the "owner" of the object and some permissions are relative to the owner. So to "copy objects between segements" you traverse the object graph and do an #assignToSegment:, You can do an #assignToSegment with nil as an argument to allow world read/write permissions. > > I thought about things like deep copying the whole tree and using > addNewVersion to change classes from one side to the other but every > approach seems rather complex. > > The last thing I tried was using Sixx as usual. I used the Published > dictionary to exchange the sixx string but wasn't successful. The > deserialized kernel displayed garbled on the web page half of the > html structure read in as string and the encoding was not correct. > > Before trying too much you probably have an idea what would be the > best/coolest/easiest way to transfer a kernel from one user to > another. I would have thought that Sixx would work. Does Pier work correctly in the upgraded 2.8 environment? For fun, I loaded the latest Pier-Model on top of a Pier2 installation (backup first:). A number of methods have been changed, so a Pier1 PRkernel probably can't be just spliced into a Pier2 installation. Probably the biggest structual change that I found is that the class PRBasicObject has been added as a superclass of PRObject in Pier2, but the names of the instance variables haven't changed, which means that SIXX should work, but that's assuming that your running the latest versions of Pier on both sides. I did notice that when I did an upgrade to a later version of Pier on Seaside alone, that the hash for some of the objets changed which caused some of the collections to become "corrupt" ... I was able to repair the "corruption" by rebuilding the collections. When I tracked the "corruption" down, I found that Pier was using the hash of an objects class as part of the hash calculation and of course in GemStone, the hash of a class can change over time...I think the experiment I did was on my home laptop, so I don't have my notes here at work ... I've been meaning to check into that problem in more detail. Nonetheless, SIXX should be rebuilding collections from scratch so I wouldn't think that hash would be an issue... SIXX should work, can you take a simple Pier kernel instance created under Seaside2.8 and load it into Pier2? If that works, add some of the elements that are not displaying correctly to your simple sample and if you see similar corruption, send me the string and I'll see if I can figure out the problem.. Dale |
Re: copying objects between segements
|
|
</off-topic>
what are Segments in Gemstone? do they have something to do with ImageSegments ? </off-topic> On Fri, Jul 30, 2010 at 7:14 PM, Dale Henrichs <[hidden email]> wrote:
|
Re: copying objects between segements
|
|
Mariano Martinez Peck wrote:
> </off-topic> > > what are Segments in Gemstone? do they have something to do with > ImageSegments ? > > </off-topic> > They are not like ImageSegments.. they are objects that are used to associate define permissions (read/write owner/group, etc.) on a per object basis. I think that we talk about them as if they were containers of some sort, but in reality each object has a slot for a segmentId in it's header and this segmentId refers to a segment object that has permissions associated with it... The name Segment is very misleading. Dale |
Re: copying objects between segements
|
|
On Fri, Jul 30, 2010 at 9:12 PM, Dale Henrichs <[hidden email]> wrote:
Ahh okok. Thanks Dale for the explanation and sorry for the offtopic. Cheers Mariano |
Re: copying objects between segements
|
|
FWIW, in GS/S 3.x "Segment" will be renamed to
"GsObjectSecurityPolicy". We hope this reduces the confusion.
On 07/30/2010 12:29 PM, Mariano Martinez Peck wrote:
-- Monty Williams Director, Product Marketing, R&D VMware +1 503 533-3506 (office) [hidden email] |
Re: copying objects between segements
|
|
In reply to this post by Dale Henrichs
On 30.07.2010, at 21:12, Dale Henrichs wrote: > Mariano Martinez Peck wrote: >> </off-topic> >> what are Segments in Gemstone? do they have something to do with ImageSegments ? >> </off-topic> > > They are not like ImageSegments.. they are objects that are used to associate define permissions (read/write owner/group, etc.) on a per object basis. I think that we talk about them as if they were containers of some sort, but in reality each object has a slot for a segmentId in it's header and this segmentId refers to a segment object that has permissions associated with it... > > The name Segment is very misleading. > Yes it is. In my opinion a user (UserProfile) is more of a segment than the segment itself ;) The segment sounds a lot like that there are partioned object memories but there aren't any. I really like the way it is in gemstone not having anything heavy like separated object memories. To me it is two things that make it work. First the global namespace is available per user login. Second, system classes are protected. Any modification to the classes will go to the UserGlobals. And if anything would go wrong the objects are assigned to a another segment so it would cause an permission denied exception. At least it is not possible to change the system classes. Well, and globals can be configured the way I needed. That is really sweet. While liking the segment idea it really makes me wonder how this done performance wise. I think here the write operations are much easier. They go through a write barrier anyway so not too heavy to add security checks I think. But what about reads? What strategies does gemstone take to not face a big performance penalty? The only thing I can imagine is that there is a check if the sender and receiver are in the same segment. And if they are then there is no security check at all. But is there else to make this doable? thanks in advance, Norbert |
Re: copying objects between segements
|
|
Norbert Hartl wrote:
> On 30.07.2010, at 21:12, Dale Henrichs wrote: > >> Mariano Martinez Peck wrote: >>> </off-topic> >>> what are Segments in Gemstone? do they have something to do with ImageSegments ? >>> </off-topic> >> They are not like ImageSegments.. they are objects that are used to associate define permissions (read/write owner/group, etc.) on a per object basis. I think that we talk about them as if they were containers of some sort, but in reality each object has a slot for a segmentId in it's header and this segmentId refers to a segment object that has permissions associated with it... >> >> The name Segment is very misleading. >> > Yes it is. In my opinion a user (UserProfile) is more of a segment than the segment itself ;) The segment sounds a lot like that there are partioned object memories but there aren't any. I really like the way it is in gemstone not having anything heavy like separated object memories. To me it is two things that make it work. First the global namespace is available per user login. Second, system classes are protected. Any modification to the classes will go to the UserGlobals. And if anything would go wrong the objects are assigned to a another segment so it would cause an permission denied exception. At least it is not possible to change the system classes. > Well, and globals can be configured the way I needed. That is really sweet. > > While liking the segment idea it really makes me wonder how this done performance wise. I think here the write operations are much easier. They go through a write barrier anyway so not too heavy to add security checks I think. But what about reads? What strategies does gemstone take to not face a big performance penalty? The only thing I can imagine is that there is a check if the sender and receiver are in the same segment. And if they are then there is no security check at all. But is there else to make this doable? > > thanks in advance, > > Norbert I haven't looked at the code to see exactly how it is done, but the GemStone vm is a copying vm in that objects are copied from the Shared Page Cache into the vm's objects space (at which time oop references are converted to pointer references. So, before an object is copied into memory from the SPC, a determination can be made whether the user has read access to the object. At read time a bit can be set in the object header indicating whether the user has write permission ... Dale |
«
Return to GLASS
|
1 view|%1 views
| Free forum by Nabble | Edit this page |