[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