Two store questions

> Reinout, what was the purpose of your response?

You are not the first one to ask...

It was a cheap joke:

In the 'good old days' programmers would share a block of wood called the
'commit token'. Only the person in possesion of the token was allowed to
commit source into the SCM system. Either having Cincom fix this bug or
instituting a physical commit token would prevent this problem from
recurring.


I'll crawl back under my rock now,

R
-

Reinout Heeck wrote:

Thanks for the explanation.  And, there's no need to crawl under a rock. :-)

Chris

Alan and others,

My question is:  did  anybody else came across the same problem ? How
big of a problem it represents?  Maybe since the Pkg. version is just a
text field with no references, I can manually fix it via SQL update
statement and forget whole accident?

I can put constraints and  handle the commit failure in some nice way. I
am not an expert on all of the Store internals, so whatever solutions I
can come up with may break some other store built in assumptions.

I do think that the tool vendor (Cincom) should anticipate the
concurrence conflict like that and at very least suggest some kind of
work around.

--Mark

Alan Knight wrote:

Mark: sure, just go in and edit the version number in the table. I did
that just a couple of days ago, when one of our developers published a
bug fix to 0.9 as 9.1 instead of 0.9.1 :-). I did it with SQLServer's
Excel-like view of the table contents - it would be nice to know if
there's a way to edit the Store Package object in the image and tell it
to update the db.

Steve

It's not transactions in Store, it's transactions. I don't know what you mean by a gating process. If you mean check ahead of time, then that won't work in general, because there may be another transaction in progress hasn't committed its results yet (that's also what it does now). If you mean allow only one person to publish at a time, that seems a rather drastic limitation to a team programming tool. Perhaps you mean something else.

At 12:25 PM 2/24/2006, Charlie Adams wrote:
--
Alan Knight [|], Cincom Smalltalk Development
[hidden email]
[hidden email]
http://www.cincom.com/smalltalk

"The Static Typing Philosophy: Make it fast. Make it right. Make it run." - Niall Ross

At 12:14 PM 2/24/2006, Reinout Heeck wrote:
I wouldn't consider it code corruption. You have two versions with the same name, but with presumably different users and which in any case can be distinguished and can be renamed, reblessed, or otherwise dealt with to further distinguish them.

Oddly, I don't ever recall hearing this as a complaint against ENVY, which also allowed it, as I suspect most transactionally-backed systems would. And for any distributed source code control system it's an inevitable problem. So, for example, multiple Store databases, or Monticello.

I can put it on the to do list, but I don't consider it a top priority.


--
Alan Knight [|], Cincom Smalltalk Development
[hidden email]
[hidden email]
http://www.cincom.com/smalltalk

"The Static Typing Philosophy: Make it fast. Make it right. Make it run." - Niall Ross

Well, I am couching this in terms that do not fit database. Like I said, I
really don't know much about database workings. If you say it cannot be
avoided then so be it. Yes, it is an esoteric problem. And has garnered far
more conversation than it deserves. I'll be quiet now and worry about my own
mountain of problems.

----- Original Message -----
From: "Alan Knight" <[hidden email]>
To: "Charlie Adams" <[hidden email]>; <[hidden email]>
Sent: Friday, February 24, 2006 1:53 PM
Subject: Re: Two store questions

Alan Knight wrote:
> >
> >Fail-fast seems wise in this case, I prefer such a solution over letting
> > code corruption happen silently. Will Cincom put this on their to-do
> > list?
>
> I wouldn't consider it code corruption. You have two versions with the same
> name, but with presumably different users and which in any case can be
> distinguished and can be renamed, reblessed, or otherwise dealt with to
> further distinguish them.

It is this 'dealing with' that I expect to be assisted by Store, regardless of
whether we call it 'code corruption', 'repository corruption' or 'build
fragility' or whatever.
Dealing retroactively with this class of problems is far more expensive than
having it fail fast programmatically.

> Oddly, I don't ever recall hearing this as a complaint against ENVY, which
> also allowed it, as I suspect most transactionally-backed systems would.
> And for any distributed source code control system it's an inevitable
> problem. So, for example, multiple Store databases, or Monticello.

I find that a lame excuse to sidestep a problem, but note that in the case of
Store I may be overly sensitive to this argument since I've said in the past
that as long as the Store team aspires to the possibilities of past VC
implementations it will not live up to the expectations of the present.

More to the point: the OP said that it happend a couple of times in three
years so it simply _is_ a complaint, regardless of what is reported for other
environments.

> I can put it on the to do list, but I don't consider it a top priority.

I can understand that, I'll consider adding the constraint to our DBs
ourselves (so it is minimally fail-fast) but it would be nice if a patch
would be published that catches this situation and explains it to the user.


R
-

Alan Knight wrote:
Alan,

I'm rather surprised that you think that this behavior is acceptable,
and more surprised to find that you think it's unavoidable. You've been
working with transactional systems at least as long as I have, and it's
been drilled into my head that any reasonable design must detect and
respond appropriately to conflicts between concurrent transactions.

I don't think it's even that hard to fix this.


Here's one approach. Let me know if you find flaws in it.

I assume a single atomic publish of multiple bundles and multiple
packages. Other cases are similar, but slightly simpler.

The first requirement is that the entire publish be done in a single
database transaction. This should already be the case, or it would be
possible for a crash in the middle of a publish to leave a half-done
publish visible in the database.

I assume that Store is using Read Committed isolation level, which I
believe is the default on most databases.


The basic steps:

1. Begin the publish transaction.

2. Do the inserts (and updates, if any, but it looks from the schema
like Store publishes by inserting new rows) to all tables except
TW_BUNDLE and TW_PACKAGE.

3. Acquire table locks on TW_BUNDLE and TW_PACKAGE, in a predefined
order to prevent deadlock. Once acquired, we know that no other
concurrent transaction can update these tables until our transaction ends.

4. For each bundle or package being published, query to see if anyone
has already used the version number we intend to use. If any such
conflicts are found, go to step 5b. Otherwise, continue with 5a.

5a. Success. Insert our new rows in TW_BUNDLE and TW_PACKAGE, commit,
and release the locks.

5b. Failure. Rollback our transaction and notify the user that the
publish failed. The user can then take whatever action is appropriate in
the development organization, such as publishing with a different
number, merging with the other developer's changes, picking up the phone
and yelling at the other developer....



This approach, if followed by all updaters, guarantees that you cannot
get duplicate package or bundle versions in the database. Because it
only locks the tables for a small fraction of the publish time, in most
cases no one will have to wait. If two publishes do happen close enough
together, one will wait until the locks are available. Since the locks
are held for a small fraction of the total publish time, this delay may
not even be noticed.


Because the SQL standard does not specify table locking, the exact means
of acquiring the table locks varies between database vendors. Oracle and
PostgreSQL use the LOCK TABLE command. SQL Server piggybacks a locking
hint on another command. I haven't looked at the documentation for other
common databases, but they all should have some way of doing this.


-Martin

Hi,

There are many times that I find myself creating new methods that do not get
packaged the way I want them to be; that is, in the same packages as the
classes they belong to.  Then because the methods aren't in the package I
expect them to be in they don't get saved when I publish a new version of
the package.  Must it be necessary to be continuously setting the current
package as I blaze my coding trail?  Am I missing some simple option or
idea?

Thanks,

-Carl Gundel, author of Liberty BASIC
http://www.libertybasic.com

Carl Gundel wrote:

In "Settings-Store-Default Package" you can set the following options,

For a new class:
- Current
- Prompt

For a new method:
- Current
- Current or class package
- Class package
- Class if same as current
- Class if same as current or none
- Always prompt

For a new variable:
- Current
- Current or class package
- Class package
- Class if same as current
- Class if same as current or none
- Always prompt

Hope this helps,

-Boris

...... Original Message .......
On Sun, 26 Feb 2006 10:23:39 -0800 Boris Popov <[hidden email]> wrote:
>Carl Gundel wrote:
>> Hi,
>>
>> There are many times that I find myself creating new methods that do not
get
Yes, that's very helpful.  :-)  I'm glad I asked.

Thanks.

-Carl

At 02:29 PM 2/25/2006, Martin McClure wrote:
>Alan,
>
>I'm rather surprised that you think that this behavior is acceptable, and more surprised to find that you think it's unavoidable. You've been working with transactional systems at least as long as I have, and it's been drilled into my head that any reasonable design must detect and respond appropriately to conflicts between concurrent transactions.

Well, I think it's a problem, I just don't consider it all that severe. I've mostly only ever worked with version control systems that had this property, and it hasn't been all that big a deal. Reinout's point that "no worse than everybody else" isn't much of a standard to aspire to is well taken, though. Part of the reason, I guess, is that it's not what I would normally consider a concurrency conflict, or at least it's a not very harmful sort of one. No data is lost or overwritten. You get two versions that share a name, but are still distinguishable and can be manipulated individually. Also, nowadays versioning systems that rely on a single centralized point of control are less interesting than those that can be distributed, and in a distributed system this really is unavoidable.

And I didn't say it was unavoidable, in fact my initial message suggested a way to avoid it by putting a unique constraint on pundle name + version. I would say that what you propose here is a slow, manual way of implementing that unique constraint that would annoy the Smalltalk developer forced to live with those constraints and give DBAs fits by ignoring integrity considerations and using full table locks to control concurrency. A solution that "only" needs to hold a full write lock on a table while it does one or more full scans of that table for duplicates is not going to meet with a lot of favour from database people.

As below, I think you can get rid of the write order constraints, so this would have the advantage that you wouldn't have to figure out for each database how it non-portably reports an integrity constraint violation, but has the disadvantage that you have to figure out how to non-portably do table locking, and that it's likely to be a good bit less performant.

>I don't think it's even that hard to fix this.

If you think the solution below is not that hard, I think you've been spending too much time working with easy to use object-oriented persistent storage mechanisms :-)

>Here's one approach. Let me know if you find flaws in it.
>
>I assume a single atomic publish of multiple bundles and multiple packages. Other cases are similar, but slightly simpler.

Actually, what happens is that each package is published in its own transaction. But WLOG we can pretend it's the same thing, and that we only care about writing a single package.
...

>The basic steps:
>
>1. Begin the publish transaction.
>
>2. Do the inserts (and updates, if any, but it looks from the schema like Store publishes by inserting new rows) to all tables except TW_BUNDLE and TW_PACKAGE.

Yes, Store is insert-only. It will never update or delete (except in GC).

I rather suspect that thoroughly changing the order in which the writes are done is a non-trivial (in the best theoretical computer science sense of the word) change. Also, much of what Store writes are link table entries, linked to the package. In everything but the first publish, it's going to be the vast majority of things. That means they need the primary key of the package, which normally is only acquired just before (or on some databases, like SQL Server, just after) the package record is written. So you're going to have a problem writing those. Even on databases where we can acquire the key before writing, it won't work if there are integrity constraints in the database. Store doesn't have those by default, but people do add them, especially in places that have fussy DBAs.

Fortunately, I don't think this is a fatal problem, because you don't actually have to do this. Just write the package table entry first, or whenever you normally would. If you're planning to roll back the transaction if there's a conflict, then it doesn't matter whether you waited to write it or not. And you can still acquire your (ick) table lock at the end, you'd just want to check if there are two of the version name in question for that package.

That would make this simpler, but still a good bit more complicated than just relying on the database facilities intended to provide this sort of behaviour.

--
Alan Knight [|], Cincom Smalltalk Development
[hidden email]
[hidden email]
http://www.cincom.com/smalltalk

"The Static Typing Philosophy: Make it fast. Make it right. Make it run." - Niall Ross

At 11:37 AM 2/25/2006, Reinout Heeck wrote:
What do you want it to do in terms of dealing with it? My tendencies would be to either
  - bless one of them as broken, merge things together and republish
  - garbage collect one of them, merge things together and republish

Both of these seem reasonably well-supported, so the dealing with doesn't seem to me to be a problem, just the detection or prevention in the first place.

--
Alan Knight [|], Cincom Smalltalk Development
[hidden email]
[hidden email]
http://www.cincom.com/smalltalk

"The Static Typing Philosophy: Make it fast. Make it right. Make it run." - Niall Ross

Carl:

Under Store settings there is an option entitled "default package" , if I  
understand you correctly you want the option "class package" for the event  
of a "new method", I believe that should work but of course the safest  
option would be to "always prompt" therefore giving you option and perhaps  
peace of mind.

-Charles

On Sat, 25 Feb 2006 18:33:19 -0500, Carl Gundel <[hidden email]>  
wrote:



--
Charles A. Monteiro

Alan Knight wrote:
> What do you want it to do in terms of dealing with it? My tendencies would
> be to either - bless one of them as broken, merge things together and
> republish - garbage collect one of them, merge things together and
> republish
>
> Both of these seem reasonably well-supported, so the dealing with doesn't
> seem to me to be a problem, just the detection or prevention in the first
> place.

Debugging this problem will cost us a pair as well as several pairs twiddling
their thumbs until the SCM is fixed. So where you see above repair methods as
supported I see them as expensive.

Having the db corruption not occur (tell the user to restart the publishing
process) is what makes it affordable for us.




R
-

Alan Knight wrote:

> Part of the reason, I guess, is that it's not what I would
> normally consider a concurrency conflict, or at least it's a not very
> harmful sort of one. No data is lost or overwritten. You get two versions
> that share a name, but are still distinguishable and can be manipulated
> individually.

You are manipulating the wrong level of abstraction here, Store is not a
database, it is a SCM system. So at the database level there is corruption
that -you seem to be telling us- is not corruption, at the SCM level though
it is simply broken. Our development process will either stall or silently
fail (version skew) on this. We don't expect duplicate version numbers in the
model that Store presents us, so they shouldn't occur.


> Also, nowadays versioning systems that rely on a single
> centralized point of control are less interesting than those that can be
> distributed, and in a distributed system this really is unavoidable.

I think that conclusion is in error. Provided the systems can contact each
other this problem is detectable and should not lead to a successful commit.
Various algorithms exist for distributed resource acquisition.
Anyway this all is moot, I don't expect Store store will ever become a
distributed system (in the clean sense, with proper transactions).


[...]
> integrity constraints in the
> database. Store doesn't have those by default, but people do add them,
> especially in places that have fussy DBAs.

especially in places that have programmers that want to do continuous
integration without having to pray. Asking for tools we can actually trust is
not exactly fussy IMO...

Store and our build scripts each form a single point of failure in our
development process, hence we _need_ them to be more robust than say a single
image. One pair loosing an image is usually cheaper for us than several pairs
waiting for the DB or build to be repaired.


I snipped the technical discussion since it is above my head. I can only read
between the lines and conclude that databases are not up to the simple tasks
Store requires, something I find hard to believe...


R
-

question:

would not normal "replication" i.e. not because of cuncurrency issues,  
cause the same problem i.e. if it is a problem in the first place. If I  
replicate my package Foo 1.5 and Bob replicates his package Foo 1.5 do we  
not get two Foo 1.5? Well, except for the fact that they have different  
timestamps and different users. I guess duplicate version strings does not  
seem to annoy me as much as some. My automated build process does not rely  
on it. I also don't find it all that confusing when I look at my published  
packages. I guess we don't do "continuous integration" whatever that  
means. For us integration is a manual scrutinized process i.e.  
"integration ready" packages are merged and we make sure to review at a  
line item level what makes it into the build. A review is often a quick  
glance so not as time consuming as it may sound and we also generate a  
report of what got merged and why i.e. we extended the tool to report what  
it did and can refer to it if something comes up.

-Charles


On Tue, 28 Feb 2006 05:30:25 -0500, Reinout Heeck <[hidden email]> wrote:



--
Charles A. Monteiro

Charles A. Monteiro wrote:
> question:
>
> would not normal "replication" i.e. not because of cuncurrency issues,
> cause the same problem i.e. if it is a problem in the first place. If I
> replicate my package Foo 1.5 and Bob replicates his package Foo 1.5 do we
> not get two Foo 1.5?

We use the Glorp-based replicator, it adds the repository name to the version
string if the version already exists in the target repository.
I assume the same race condition exists in the replicator's test for presence
of a version as Store has.

> Well, except for the fact that they have different
> timestamps and different users.

> I guess duplicate version strings does not
> seem to annoy me as much as some. My automated build process does not rely
> on it.

Ours does, to reduce (not eliminate) version instability *during* a build we
do a walk of all the prerequisites prior to building, resolving them to a
version using a 'newest with blessing level above X' approach. After this
list is built the system starts to build, loading packages only from this
list. So if another version is published during the build with the same
version string we get problems.

> I also don't find it all that confusing when I look at my published
> packages. I guess we don't do "continuous integration" whatever that
> means.

Merging and publishing several times (1..20) per day by all pairs and
immediately starting a new build after publishing. This way we validate (by
using it) the integration results at the earliest time possible while taking
small incremental steps. Moreover we don't get a n-way 'merge from hell' that
everybody would suffer if done at the end of the day.


> For us integration is a manual scrutinized process i.e.
> "integration ready" packages are merged and we make sure to review at a
> line item level what makes it into the build.
> A review is often a quick
> glance so not as time consuming as it may sound and we also generate a
> report of what got merged and why i.e. we extended the tool to report what
> it did and can refer to it if something comes up.
>
> -Charles

if you don't mind me asking, how many developers are we talking about i.e.  
that actively involved on a day to day basis in the process you describe  
below.


thanks

-Charles

On Tue, 28 Feb 2006 09:46:45 -0500, Reinout Heeck <[hidden email]> wrote:



--
Charles A. Monteiro