Smalltalk › Cincom › VisualWorks

GUI and Gemstone

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

12 messages Options

Nel, Dirk

GUI and Gemstone

Hi there everyone

This will be my first posting to this list.

I work in a company that uses Visual Works 7.4 along with Gemstone. The system that I'm working on has been in constant development for this past 8 years so it is quite large. There are different apporaches in user interface design in the system. Some views are DomainAdaptors with accessors. The problem with this approach is that the database needs to be in a transaction the whole time the view is open (if the reason for this is not clear I can eloborate). The other approach in our system is that we use normal value holders that do not create the same problem as accessors.

Out chief designer also does not like the fact that there is basically a one to one mapping between our objects and the UI. So there are also places where there are wrappers that are the interface between our objects and the UI.

Just want to pick brains about how other developers using Gemstone do their UI.

Any thoughts,

Dirk Nel

012 671 8296
082 782 2676

"From today on, I do the Will of God, everywhere, always and in everything." Saint Maria Faustina Kowalski (February 4 1935)

This e-mail and any files transmitted with it contain confidential and privileged information intended solely for the use of the individual to whom they are addressed.

If you received this e-mail in error please inform the sender and delete it. You may not use/distribute or copy it or take any action as a consequence of its content.

Recipients are reminded that e-mail is an insecure communication medium and we accept no responsibility for any losses, incurred as a result of fictitious or falsified messages. If in doubt recipients should take action to verify the authenticity of any message received.

This footnote also confirms that this e-mail message has been swept by MIMEsweeper for the presence of computer viruses. E-mails and their contents can be monitored.

RMB Investment Services Limited is licensed by the Guernsey Financial Services Commission to conduct Investment Business.

A member of the FirstRand Group

This email and all content are subject to the following disclaimer:

http://content.momentum.co.za/content/legal/disclaimer_email.htm

Reinout Heeck-2

Re: GUI and Gemstone

We limit the time the user can keep the view open. After a while a warning
is displayed. If the user keeps the view open after a second warning we
kill the session. All in all the user has about 30 minutes to do his job.
This works fine, maybe except for a few complex views.

HTH,
Adriaan.

> Hi there everyone
>
> This will be my first posting to this list.
>
> I work in a company that uses Visual Works 7.4 along with Gemstone. The
> system that I'm working on has been in constant development for this past
> 8 years so it is quite large. There are different apporaches in user
> interface design in the system. Some views are DomainAdaptors with
> accessors. The problem with this approach is that the database needs to
> be in a transaction the whole time the view is open (if the reason for
> this is not clear I can eloborate). The other approach in our system is
> that we use normal value holders that do not create the same problem as
> accessors.
>
> Out chief designer also does not like the fact that there is basically a
> one to one mapping between our objects and the UI. So there are also
> places where there are wrappers that are the interface between our objects
> and the UI.
>
> Just want to pick brains about how other developers using Gemstone do
> their UI.
>
> Any thoughts,
>
> Dirk Nel
>
> 012 671 8296
> 082 782 2676
>
> "From today on, I do the Will of God, everywhere, always and in
> everything." Saint Maria Faustina Kowalski (February 4 1935)
>
>
>
> This e-mail and any files transmitted with it contain confidential and
> privileged information intended solely for the use of the individual to
> whom they are addressed.
>
> If you received this e-mail in error please inform the sender and delete
> it. You may not use/distribute or copy it or take any action as a
> consequence of its content.
>
> Recipients are reminded that e-mail is an insecure communication medium
> and we accept no responsibility for any losses, incurred as a result of
> fictitious or falsified messages. If in doubt recipients should take
> action to verify the authenticity of any message received.
>
> This footnote also confirms that this e-mail message has been swept by
> MIMEsweeper for the presence of computer viruses. E-mails and their
> contents can be monitored.
>
> RMB Investment Services Limited is licensed by the Guernsey Financial
> Services Commission to conduct Investment Business.
>
> A member of the FirstRand Group
>
> This email and all content are subject to the following disclaimer:
>
> http://content.momentum.co.za/content/legal/disclaimer_email.htm
>
>
>

--
http://vdg38bis.xs4all.nl

Charles A. Monteiro-2

Re: GUI and Gemstone

its imperative that transactions are kept short or there is the risk of
getting into commit record backlog issues. Caveat, I have not worked with
the new versions of Gemstone which seems to have fixed most of anything I
recall having issues with. In anycase its probably still best to keep
transactions very atomic. What I and colleagues have done is to use an
extension of the BufferedValueHolder approach i.e. updates to the object
or set of objects are captured but not flushed to the object until a
specific event occurs i.e. the "trigger channel" is tripped (updated). In
our case were were not in an automatic transaction mode but rather would
do manual begin and commits for the purposes of keeping transaction
windows short. Or from a different perspective only as long as required to
do the updates.

hth

-Charles

On Tue, 29 Aug 2006 05:35:22 -0400, Adriaan van Os <[hidden email]>
wrote:

> We limit the time the user can keep the view open. After a while a
> warning
> is displayed. If the user keeps the view open after a second warning we
> kill the session. All in all the user has about 30 minutes to do his job.
> This works fine, maybe except for a few complex views.
>
> HTH,
> Adriaan.
>
>
>> Hi there everyone
>>
>> This will be my first posting to this list.
>>
>> I work in a company that uses Visual Works 7.4 along with Gemstone. The
>> system that I'm working on has been in constant development for this
>> past
>> 8 years so it is quite large. There are different apporaches in user
>> interface design in the system. Some views are DomainAdaptors with
>> accessors. The problem with this approach is that the database needs to
>> be in a transaction the whole time the view is open (if the reason for
>> this is not clear I can eloborate). The other approach in our system is
>> that we use normal value holders that do not create the same problem as
>> accessors.
>>
>> Out chief designer also does not like the fact that there is basically a
>> one to one mapping between our objects and the UI. So there are also
>> places where there are wrappers that are the interface between our
>> objects
>> and the UI.
>>
>> Just want to pick brains about how other developers using Gemstone do
>> their UI.
>>
>> Any thoughts,
>>
>> Dirk Nel
>>
>> 012 671 8296
>> 082 782 2676
>>
>> "From today on, I do the Will of God, everywhere, always and in
>> everything." Saint Maria Faustina Kowalski (February 4 1935)
>>
>>
>>
>> This e-mail and any files transmitted with it contain confidential and
>> privileged information intended solely for the use of the individual to
>> whom they are addressed.
>>
>> If you received this e-mail in error please inform the sender and delete
>> it. You may not use/distribute or copy it or take any action as a
>> consequence of its content.
>>
>> Recipients are reminded that e-mail is an insecure communication medium
>> and we accept no responsibility for any losses, incurred as a result of
>> fictitious or falsified messages. If in doubt recipients should take
>> action to verify the authenticity of any message received.
>>
>> This footnote also confirms that this e-mail message has been swept by
>> MIMEsweeper for the presence of computer viruses. E-mails and their
>> contents can be monitored.
>>
>> RMB Investment Services Limited is licensed by the Guernsey Financial
>> Services Commission to conduct Investment Business.
>>
>> A member of the FirstRand Group
>>
>> This email and all content are subject to the following disclaimer:
>>
>> http://content.momentum.co.za/content/legal/disclaimer_email.htm
>>
>>
>>
>
>

--
Charles A. Monteiro
http://wiki.nycsmalltalk.org
http://www.monteirosfusion.com
http://monteirofusion.blogspot.com

Dennis smith-4

Re: GUI and Gemstone

In reply to this post by Reinout Heeck-2

We do something similar to Adriaan.

We open the GUI on the real object which exists on both VW and Gemstone. Then when the
user asks to change or add we start a transaction. This transaction starts warning the user after
20min (we don't get much commit-record backlog in that period), and kicks him off after 45min
(both numbers configurable).

We also have a mode where we work on a copy. This has disadvantages:
1. "self" is wrong, so if we try and link the object we are working on into somewhere (pointer to it) its a problem.
2. it takes time to do the copy, particularly if its a complex object with its own hierarchy of objects.

We use this "copy" mode for making temporary changes to something that need to exist for long periods.
One example is where we want to print a report, and we have an object which holds the report options.
We want to make a temporary change and print the report.

We also use the "copy" mode for web-based applications.

We use the direct open-transaction mode for all other GUI apps.

Adriaan van Os wrote:

We limit the time the user can keep the view open. After a while a warning
is displayed. If the user keeps the view open after a second warning we
kill the session. All in all the user has about 30 minutes to do his job.
This works fine, maybe except for a few complex views.

HTH,
Adriaan.

Hi there everyone

This will be my first posting to this list.

I work in a company that uses Visual Works 7.4 along with Gemstone.  The
system that I'm working on has been in constant development for this past
8 years so it is quite large.  There are different apporaches in user
interface design in the system.  Some views are DomainAdaptors with
accessors.  The problem with this approach is that the database needs to
be in a transaction the whole time the view is open (if the reason for
this is not clear I can eloborate).  The other approach in our system is
that we use normal value holders that do not create the same problem as
accessors.

Out chief designer also does not like the fact that there is basically a
one to one mapping between our objects and the UI.  So there are also
places where there are wrappers that are the interface between our objects
and the UI.

Just want to pick brains about how other developers using Gemstone do
their UI.

Any thoughts,

Dirk Nel

012 671 8296
082 782 2676

"From today on, I do the Will of God, everywhere, always and in
everything." Saint Maria Faustina Kowalski (February 4 1935)



This e-mail and any files transmitted with it contain confidential and
privileged information intended solely for the use of the individual to
whom they are addressed.

If you received this e-mail in error please inform the sender and delete
it. You may not use/distribute or copy it or take any action as a
consequence of its content.

Recipients are reminded that e-mail is an insecure communication medium
and we accept no responsibility for any losses, incurred as a result of
fictitious or falsified messages. If in doubt recipients should take
action to verify the authenticity of any message received.

This footnote also confirms that this e-mail message has been swept by
MIMEsweeper for the presence of computer viruses. E-mails and their
contents can be monitored.

RMB Investment Services Limited is licensed by the Guernsey Financial
Services Commission to conduct Investment Business.

A member of the FirstRand Group

This email and all content are subject to the following disclaimer:

http://content.momentum.co.za/content/legal/disclaimer_email.htm

-- 
Dennis Smith                        [hidden email]
Cherniak Software Development Corporation       +1 905.771.7011
400-10 Commerce Valley Dr E                Fax: +1 905.771.6288
Thornhill, ON Canada L3T 7N7    http://www.CherniakSoftware.com

Joseph Bacanskas-4

Re: GUI and Gemstone

In reply to this post by Nel, Dirk

Hi Dirk:

There is no technical reason for your app to stay in transaction
while a view is open. You may have a "business" reason; but if you
are also wrappers in parts of your system, there may not be a
"business" reason either.

Have you looked at the GemStone docks on SigAbort handlers?

In the app I have been supporting for years, we, for the most part,
use real domain objects in our UIs. We have very heavily tuned
replicationSpecs and get good WAN performance. Most of our "views"
do an automatic abort every 2 minutes, and will respond to a SigAbort
almost any time. We accumulate our changes until the user clicks a
"save" button. We abort, then apply all changes in a
#transactDuring: block. The #transactDuring: can be as simple as...

GBSM beginTransaction.
aBlock value.
^GBSM commitTransaction

though it is usually more complicated, since we incorporate a "re-try
loop" and sometimes lock and unlock objects, etc.

Of course, your app might need to things like object-level locking,
etc. YMMV.

I used to work on a VW Web/GemStone system. In that case, all domain
values had to be cached in the web page AppModel, depending on your
domain you might even find that sufficient.

Have you taken any of the GemStone training? You might find that
really helpful.

Good Luck!!

On Aug 29, 2006, at 1:33 AM, Nel, Dirk wrote:

> Hi there everyone
>
> This will be my first posting to this list.
>
> I work in a company that uses Visual Works 7.4 along with
> Gemstone. The system that I'm working on has been in constant
> development for this past 8 years so it is quite large. There are
> different apporaches in user interface design in the system. Some
> views are DomainAdaptors with accessors. The problem with this
> approach is that the database needs to be in a transaction the
> whole time the view is open (if the reason for this is not clear I
> can eloborate). The other approach in our system is that we use
> normal value holders that do not create the same problem as accessors.
>
> Out chief designer also does not like the fact that there is
> basically a one to one mapping between our objects and the UI. So
> there are also places where there are wrappers that are the
> interface between our objects and the UI.
>
> Just want to pick brains about how other developers using Gemstone
> do their UI.
>
> Any thoughts,
>
> Dirk Nel
>
> 012 671 8296
> 082 782 2676
>
> "From today on, I do the Will of God, everywhere, always and in
> everything." Saint Maria Faustina Kowalski (February 4 1935)
>
>
> This e-mail and any files transmitted with it contain confidential
> and privileged information intended solely for the use of the
> individual to whom they are addressed.
>
> If you received this e-mail in error please inform the sender and
> delete it. You may not use/distribute or copy it or take any action
> as a consequence of its content.
>
> Recipients are reminded that e-mail is an insecure communication
> medium and we accept no responsibility for any losses, incurred as
> a result of fictitious or falsified messages. If in doubt
> recipients should take action to verify the authenticity of any
> message received.
>
> This footnote also confirms that this e-mail message has been swept
> by MIMEsweeper for the presence of computer viruses. E-mails and
> their contents can be monitored.
>
> RMB Investment Services Limited is licensed by the Guernsey
> Financial Services Commission to conduct Investment Business.
>
> A member of the FirstRand Group
>
> This email and all content are subject to the following disclaimer:
>
> http://content.momentum.co.za/content/legal/disclaimer_email.htm

Thanks!!
Joseph Bacanskas [|]
--- I use Smalltalk. My amp goes to eleven.

Keith Piraino

Re: GUI and Gemstone

In reply to this post by Nel, Dirk

Hi Dirk,

In our GemStone application the GUI's operate directly on the real
domain objects and do so outside of a transaction. We don't buffer
things in the UI, operate on copies, or set timers to force periodic
refreshes. The trick is that when we modify the objects we don't mark
them dirty from a GemStone perspective. We maintain our own equivalent
to the dirty set. When the user presses OK/Save we start a transaction,
mark the modified objects gs dirty and commit. If another session has
modified the object in the meantime (we check for changes at every
transaction boundary) the user is prompted to decide whether to abandon
their changes or overwrite what is in the database. This mechanism
allows us to support parallel transactions. A user can edit multiple
objects simultaneously and selectively decide which changes to save.

Our approach requires building and maintaining a fairly complex bit of
infrastructure but it does make things very easy for application
developers. For more information on how others have tackled this (and
other common problems) I've attached a document that summarizes
GemStone experience reports given at a conference a few years ago.

BTW, I'm not sure I understand the objection to a "one to one mapping
between our objects and the UI". We closely follow this aspect of what
some call "naked objects":

http://www.nakedobjects.org/static.php?content=naked-objects-pattern.html

- Keith

--- "Nel, Dirk" <[hidden email]> wrote:

> Hi there everyone
>
> This will be my first posting to this list.
>
> I work in a company that uses Visual Works 7.4 along with Gemstone.
> The system that I'm working on has been in constant development for
> this past 8 years so it is quite large. There are different
> apporaches in user interface design in the system. Some views are
> DomainAdaptors with accessors. The problem with this approach is
> that the database needs to be in a transaction the whole time the
> view is open (if the reason for this is not clear I can eloborate).
> The other approach in our system is that we use normal value holders
> that do not create the same problem as accessors.
>
> Out chief designer also does not like the fact that there is
> basically a one to one mapping between our objects and the UI. So
> there are also places where there are wrappers that are the interface
> between our objects and the UI.
>
> Just want to pick brains about how other developers using Gemstone do
> their UI.
>
> Any thoughts,
>
> Dirk Nel
>
> 012 671 8296
> 082 782 2676
>
> "From today on, I do the Will of God, everywhere, always and in
> everything." Saint Maria Faustina Kowalski (February 4 1935)
>
>
>
> This e-mail and any files transmitted with it contain confidential
> and privileged information intended solely for the use of the
> individual to whom they are addressed.
>
> If you received this e-mail in error please inform the sender and
> delete it. You may not use/distribute or copy it or take any action
> as a consequence of its content.
>
> Recipients are reminded that e-mail is an insecure communication
> medium and we accept no responsibility for any losses, incurred as a
> result of fictitious or falsified messages. If in doubt recipients
> should take action to verify the authenticity of any message
> received.
>
> This footnote also confirms that this e-mail message has been swept
> by MIMEsweeper for the presence of computer viruses. E-mails and
> their contents can be monitored.
>
> RMB Investment Services Limited is licensed by the Guernsey Financial
> Services Commission to conduct Investment Business.
>
> A member of the FirstRand Group
>
> This email and all content are subject to the following disclaimer:
>
> http://content.momentum.co.za/content/legal/disclaimer_email.htm
>
>
>

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

Smalltalk Solutions 2001 Keith Piraino Notes - experience reports only.doc (34K) Download Attachment

Joseph Bacanskas-4

Re: GUI and Gemstone

Hi Keith:

A great solution, IMHO. It is flexible and scalable.

On Aug 29, 2006, at 9:45 PM, Keith Piraino wrote:

> Hi Dirk,
>
> In our GemStone application the GUI's operate directly on the real
> domain objects and do so outside of a transaction. We don't buffer
> things in the UI, operate on copies, or set timers to force periodic
> refreshes. The trick is that when we modify the objects we don't mark
> them dirty from a GemStone perspective. We maintain our own equivalent
> to the dirty set. When the user presses OK/Save we start a
> transaction,
> mark the modified objects gs dirty and commit. If another session has
> modified the object in the meantime (we check for changes at every
> transaction boundary) the user is prompted to decide whether to
> abandon
> their changes or overwrite what is in the database. This mechanism
> allows us to support parallel transactions. A user can edit multiple
> objects simultaneously and selectively decide which changes to save.
>
> Our approach requires building and maintaining a fairly complex bit of
> infrastructure but it does make things very easy for application
> developers. For more information on how others have tackled this (and
> other common problems) I've attached a document that summarizes
> GemStone experience reports given at a conference a few years ago.
>
> BTW, I'm not sure I understand the objection to a "one to one mapping
> between our objects and the UI". We closely follow this aspect of what
> some call "naked objects":
>
> http://www.nakedobjects.org/static.php?content=naked-objects-
> pattern.html
>
> - Keith
>
>
> --- "Nel, Dirk" <[hidden email]> wrote:
>
>> Hi there everyone
>>
>> This will be my first posting to this list.
>>
>> I work in a company that uses Visual Works 7.4 along with Gemstone.
>> The system that I'm working on has been in constant development for
>> this past 8 years so it is quite large. There are different
>> apporaches in user interface design in the system. Some views are
>> DomainAdaptors with accessors. The problem with this approach is
>> that the database needs to be in a transaction the whole time the
>> view is open (if the reason for this is not clear I can eloborate).
>> The other approach in our system is that we use normal value holders
>> that do not create the same problem as accessors.
>>
>> Out chief designer also does not like the fact that there is
>> basically a one to one mapping between our objects and the UI. So
>> there are also places where there are wrappers that are the interface
>> between our objects and the UI.
>>
>> Just want to pick brains about how other developers using Gemstone do
>> their UI.
>>
>> Any thoughts,
>>
>> Dirk Nel
>>
>> 012 671 8296
>> 082 782 2676
>>
>> "From today on, I do the Will of God, everywhere, always and in
>> everything." Saint Maria Faustina Kowalski (February 4 1935)
>>
>>
>>
>> This e-mail and any files transmitted with it contain confidential
>> and privileged information intended solely for the use of the
>> individual to whom they are addressed.
>>
>> If you received this e-mail in error please inform the sender and
>> delete it. You may not use/distribute or copy it or take any action
>> as a consequence of its content.
>>
>> Recipients are reminded that e-mail is an insecure communication
>> medium and we accept no responsibility for any losses, incurred as a
>> result of fictitious or falsified messages. If in doubt recipients
>> should take action to verify the authenticity of any message
>> received.
>>
>> This footnote also confirms that this e-mail message has been swept
>> by MIMEsweeper for the presence of computer viruses. E-mails and
>> their contents can be monitored.
>>
>> RMB Investment Services Limited is licensed by the Guernsey Financial
>> Services Commission to conduct Investment Business.
>>
>> A member of the FirstRand Group
>>
>> This email and all content are subject to the following disclaimer:
>>
>> http://content.momentum.co.za/content/legal/disclaimer_email.htm
>>
>>
>>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com

Thanks!!
Joseph Bacanskas [|]
--- I use Smalltalk. My amp goes to eleven.

attachment0 (34K) Download Attachment

Martin McClure

Re: GUI and Gemstone

In reply to this post by Nel, Dirk

Nel, Dirk wrote:
> Hi there everyone
>
> This will be my first posting to this list.
>
> I work in a company that uses Visual Works 7.4 along with Gemstone.

Hi Dirk,

You've sparked an interesting discussion, which has been continued over
on the GemStone Smalltalk Customer Forum. The GS/S forum is probably a
better place for this discussion anyway.

If you're not currently subscribed to the GS/S forum, you can subscribe
at http://earth.lyris.net/cgi-bin/lyris.pl?enter=gemstone-smalltalk and
read the archive at
http://support.gemstone.com/gemstone_s/learning_center/forum/maillist.html

Please let the forum know if you have further questions.

Regards,

-Martin

Yanni Chiu

Re: GUI and Gemstone

Martin McClure wrote:
> Nel, Dirk wrote:
>> I work in a company that uses Visual Works 7.4 along with Gemstone.
>
> Hi Dirk,
>
> You've sparked an interesting discussion, which has been continued over
> on the GemStone Smalltalk Customer Forum. The GS/S forum is probably a
> better place for this discussion anyway.

Actually, a wider forum like c.l.s might be better, since it
seems to be a general architectural issue. After reading about
some of the techniques people have used, I was reminded of an
implementation using C++/Oracle I did, where I kept track of
the dirty objects, then executed the necessary SQL in transactions.
Much of the boilerplate code was generated. This sounds so much
like the various solutions that people have described, that I'm
somewhat disappointed to hear that people still had to do these
things, even when using GemStone.

Joseph Bacanskas-4

Re: GUI and Gemstone

Hi Yanni:

Thought the issues being discussed sound similar, they are
fundametally different than your C++/Oracle system; which is
essentially stateless. All of the posters were describing ways to
capture changes in a way that does not disrupt the *statefulness* of
a GemStone/S system. Those who use VAST had slightly different
issues to deal with than those using VW, and that sometimes explained
the difference in approach to the problem.

In any large-scale GemStone/S system, there are two major
architectural issues; how do I capture changes efficiently and how do
I balance the GemStone statefulness with the number of commits in a
large multi-user system. As you may know, GemStone guarantees each
session a consistent view of the repository. Each user holds on to a
view until they commit or abort. When you have 500 users holding
views on a 50GB repository, that is a database management issue. The
suggested "transaction frameworks" are various attempts to deal with
those issues.

As Mang described in this thread on the GemStone support list, we are
talking about "units of work". This is a basic database concept.
GemStone adds a new management dimension with consistent-view-per-
session. That dimension is managed both at a transaction framework
level and at a DBA level.

Cheers!!

On Aug 30, 2006, at 7:29 PM, Yanni Chiu wrote:

> Martin McClure wrote:
>> Nel, Dirk wrote:
>>> I work in a company that uses Visual Works 7.4 along with Gemstone.
>> Hi Dirk,
>> You've sparked an interesting discussion, which has been continued
>> over on the GemStone Smalltalk Customer Forum. The GS/S forum is
>> probably a better place for this discussion anyway.
>
> Actually, a wider forum like c.l.s might be better, since it
> seems to be a general architectural issue. After reading about
> some of the techniques people have used, I was reminded of an
> implementation using C++/Oracle I did, where I kept track of
> the dirty objects, then executed the necessary SQL in transactions.
> Much of the boilerplate code was generated. This sounds so much
> like the various solutions that people have described, that I'm
> somewhat disappointed to hear that people still had to do these
> things, even when using GemStone.
>

Thanks!!
Joseph Bacanskas [|]
--- I use Smalltalk. My amp goes to eleven.

Yanni Chiu

Re: GUI and Gemstone

Joseph Bacanskas wrote:
> Thought the issues being discussed sound similar, they are fundametally
> different than your C++/Oracle system; which is essentially stateless.
> All of the posters were describing ways to capture changes in a way
> that does not disrupt the *statefulness* of a GemStone/S system.

But don't the various approaches re-introduce the "stateless" aspect,
if I'm understanding the term correctly. By "stateful" I'm guessing
that you mean GemStone's ability to make object persistence transparent.
IMHO, if you're not using GemStone is some sort of "naked objects"
approach, then it seems that a big plus point of GemStone is not being
utilized.

> In any large-scale GemStone/S system, there are two major architectural
> issues; how do I capture changes efficiently and how do I balance the
> GemStone statefulness with the number of commits in a large multi-user
> system.

Does this mean the "naked object" approach does not scale up?

> As you may know, GemStone guarantees each session a consistent
> view of the repository.

Many relational DB's have MVCC. So does this mean that:

UOW + ORM + RDB = UOW + GemStone

So the GemStone advantage is to eliminate the object-relational
mapping, but the UOW framework is need to scale up.

> As Mang described in this thread on the GemStone support list, we are
> talking about "units of work". This is a basic database concept.
> GemStone adds a new management dimension with consistent-view-per-
> session. That dimension is managed both at a transaction framework
> level and at a DBA level.

Not sure what you mean here.

Joseph Bacanskas-4

Re: GUI and Gemstone

Hi Yanni:

On Aug 31, 2006, at 10:45 AM, Yanni Chiu wrote:

> Joseph Bacanskas wrote:
>> Thought the issues being discussed sound similar, they are
>> fundametally different than your C++/Oracle system; which is
>> essentially stateless. All of the posters were describing ways
>> to capture changes in a way that does not disrupt the
>> *statefulness* of a GemStone/S system.
>
> But don't the various approaches re-introduce the "stateless" aspect,
> if I'm understanding the term correctly. By "stateful" I'm guessing
> that you mean GemStone's ability to make object persistence
> transparent.
> IMHO, if you're not using GemStone is some sort of "naked objects"
> approach, then it seems that a big plus point of GemStone is not being
> utilized.

Absolutely; we share the same understanding of the issue.

>
>> In any large-scale GemStone/S system, there are two major
>> architectural issues; how do I capture changes efficiently and how
>> do I balance the GemStone statefulness with the number of commits
>> in a large multi-user system.
>
> Does this mean the "naked object" approach does not scale up?

IMHO, the builders of GemStone/S had a specific set of design goals.
ACID, transparent persistence of objects was a big part of those
goals. As we know, all designs are a compromise, and all designs
have places in their implementation that are vulnerable. Using
GemStone (32bit) "statefullly" will scale to ~1500 concurrent users
and at least a 100GB repository. To attain this, in a product that
was designed in the 1980's (or very early 1990's) takes a fair amount
of tuning *and* a LOT of serious hardware. But, it does scale. This
is *much* less of an issue in the 64bit product.

>
> > As you may know, GemStone guarantees each session a consistent
>> view of the repository.
>
> Many relational DB's have MVCC. So does this mean that:
>
> UOW + ORM + RDB = UOW + GemStone
>
> So the GemStone advantage is to eliminate the object-relational
> mapping, but the UOW framework is need to scale up.

Acutually it's 2 and a half things. ;-) The first you have
identified; it is a big deal. Second is that the GemStone server
allows for the execution of code in it's, rather than the client's,
VM. When you must traverse a collection of 5M objects, this too is a
big deal. Like the client image, it is alive. Third, you can
arbitrarily move behavior between client and server as appropriate.
Even though this is the "one half", this too is a big deal. You can
put behavior in an RDB via stored procedures; but you can't easily
move it from server to client, or from client to server.

>
>> As Mang described in this thread on the GemStone support list, we
>> are talking about "units of work". This is a basic database
>> concept. GemStone adds a new management dimension with
>> consistent-view-per- session. That dimension is managed both at a
>> transaction framework level and at a DBA level.
>
> Not sure what you mean here.

Only that the consistent-view-per-session can cause serious
performance issues and must be properly managed. Again, it is the
result of a design trade-off.

>

Thanks!!
Joseph Bacanskas [|]
--- I use Smalltalk. My amp goes to eleven.