[Seaside] GemStone

Todd Blanchard tblanchard at mac.com
Fri Dec 14 22:33:29 UTC 2007


Yeah, you know a little article on developing for Gemstone without  
Gemstone would be really useful for people considering making the  
jump.  At least folks could be getting ready to adopt.

-Todd Blanchard

On Dec 14, 2007, at 10:41 AM, Dale Henrichs wrote:

> Oleg,
>
> As others have mentioned you need to have the 64bit hardware to run  
> GemStone. There would be a significant amount of work for us to port  
> our 64bit product to run on 32 bit architectures, so we won't be  
> heading in that directions.
>
> We have recently announced a non-commercial version of GemStone 6.2  
> is available for the Mac (Tiger on x86). GemStone 6.x is the 32 bit  
> line of our server. This is an option that could be followed.
>
> On the other hand, if you are developing an application (with plans  
> to deploy on GemStone), then it is actually a very good strategy to  
> develop in Squeak and deploy in GemStone. Our first GLASS customer  
> to go into production did just that. They started developing their  
> application in Squeak long before we even a beta ready for GemStone  
> (in fact they did their development using Seaside2.7), then when we  
> had our beta ready they ported their application from Squeak to  
> GemStone (using Seaside2.8).
>
> As Boris has mentioned, taking advantage of GemStone persistence is  
> as simple as storing things in class variables. Anything that is  
> kept alive in your Squeak image will be kept alive (and persisted)  
> in GemStone. In a Seaside application, the framework does the  
> commits, so there is literally no need to change you application  
> when you move it to GemStone. A good set of unit tests is  
> recommended, but then thats a good idea no matter what your  
> deployment plans are.
>
> You _do_ have to be more aware of concurrency issues in a GemStone  
> application than you do in an image-based application. Intra-session  
> data structure access is protected by object locking in the  
> framework, but for data structures that may be updated by multiple  
> sessions (places where you would be using Semaphores to protect data  
> access in a Squeak Seaside application) you will likely need to use  
> some GemStone-specific reduced conflict classes.  I have plans to  
> write a blog post to cover the options in more detail - after  
> today's discussion, I will probably write it sooner rather than later.
>
> In general, you will be doing very little GemStone/persistence- 
> specific code in a Seaside application that is targeted to be  
> deployed in GemStone.
>
> In the end, I think it is very possible (and even desirable) to  
> develop your Seaside app in Squeak with plans to deploy in GemStone.  
> I would think that you can get away with doing quite a bit of  
> development, before really needing to get access to GemStone and 64  
> bit hardware.
>
> Dale
>
>
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside



More information about the seaside mailing list