You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Kevin Williams <ke...@qwest.net> on 2006/10/17 22:31:25 UTC
[DAS] TUSCANY-866: Default OCC policy
Brent,
This sounds reasonable but we probably want some mechanism to provide our previous default policy which is "no collision checking". Maybe a piece of config. What do you think?
--
Kevin
[DAS] Use overqualified update by default
-----------------------------------------
Key: TUSCANY-866
URL: http://issues.apache.org/jira/browse/TUSCANY-866
Project: Tuscany
Issue Type: New Feature
Components: Java DAS RDB
Reporter: Brent Daniel
Currently in the DAS we either use a user-defined version column or do not use any concurrency control. We have enough information to build an overqualified update in cases where a version column is not defined. For example, if a field "name" is changed from "Bob" to "John", we would generate a query such as:
UPDATE CUSTOMER SET NAME = 'John' WHERE ID = 1 AND NAME = 'Bob'
If the statement does not update any rows in the database, the DAS will throw a concurrency control exception.
This scheme will not work in case of LONG VARCHAR, BLOB, or CLOB columns, so an exception should be thrown in that case indicating that a version column must be defined.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [DAS] TUSCANY-866: Default OCC policy
Posted by Brent Daniel <br...@gmail.com>.
Hi Amita,
Unfortunately I had to drop this rather suddenly, so it would be
great if you could pick this up. The code I have, if I can find it,
probably isn't even relevant anymore.
At a high level, my goals for recovery were to ensure that all
information on the failure was available and that users could easily
employ a strategy to recover. For the first goal, the user should know
which DataObject resulted in the OCC failure, and should have the
current and original values for that DO. For the second goal, I was
headed down the path of having a utility that would allow you to
"force" the changes (ignoring OCC failures), read the current DB
values to either illustrate what field is causing the collision or
just update the graph with the current state of that DO, or roll back
the changes to the current DataObject.
I think the important first step here is making sure the information
is available. I had planned on having an OCCException that would get
thrown after a collision which would contain this information (in
accordance with DAS design goals, this would have to extend
RuntimeException).
Brent
On 6/13/07, Amita Vadhavkar <am...@gmail.com> wrote:
> Please let me know what is there in code base at present/in-progress for OCC
> recovery? Will you please elaborate the approach and if there is any item I
> can pick up for next release?
>
> Regards,
> Amita
>
>
> On 10/18/06, Brent Daniel <br...@gmail.com> wrote:
> >
> > I've been working on some function to recover from collisions (since
> > at the moment we have none :) ). One of the recovery mechanisms I'm
> > planning to put in is a means to "force" the update. Though it would
> > require an extra step, this should take care of this case.
> >
> > Brent
> >
> > On 10/17/06, Kevin Williams <ke...@qwest.net> wrote:
> > > I have talked to clients that want their data slammed into the database
> > > no matter what. But, this is an edge case. We can wait for someone to
> > > ask for it ... or contribute it.
> > >
> > > Brent Daniel wrote:
> > >
> > > > Kevin,
> > > >
> > > > We can do that, but it will be our fourth different way to specify
> > > > OCC behavior (default, version column, managed version column, and
> > > > none.) Is there a good use case for this? It seems like the only time
> > > > you would want to go without concurrency control is when you have
> > > > read-only tables, and in that case this behavior would never be
> > > > reached anyway.
> > > >
> > > > Brent
> > > >
> > > > On 10/17/06, Kevin Williams <ke...@qwest.net> wrote:
> > > >
> > > >> Brent,
> > > >> This sounds reasonable but we probably want some mechanism to provide
> > > >> our previous default policy which is "no collision checking". Maybe
> > > >> a piece of config. What do you think?
> > > >> --
> > > >> Kevin
> > > >>
> > > >>
> > > >>
> > > >> [DAS] Use overqualified update by default
> > > >> -----------------------------------------
> > > >>
> > > >> Key: TUSCANY-866
> > > >> URL: http://issues.apache.org/jira/browse/TUSCANY-866
> > > >> Project: Tuscany
> > > >> Issue Type: New Feature
> > > >> Components: Java DAS RDB
> > > >> Reporter: Brent Daniel
> > > >>
> > > >>
> > > >> Currently in the DAS we either use a user-defined version column or
> > > >> do not use any concurrency control. We have enough information to
> > > >> build an overqualified update in cases where a version column is not
> > > >> defined. For example, if a field "name" is changed from "Bob" to
> > > >> "John", we would generate a query such as:
> > > >>
> > > >> UPDATE CUSTOMER SET NAME = 'John' WHERE ID = 1 AND NAME = 'Bob'
> > > >>
> > > >> If the statement does not update any rows in the database, the DAS
> > > >> will throw a concurrency control exception.
> > > >>
> > > >> This scheme will not work in case of LONG VARCHAR, BLOB, or CLOB
> > > >> columns, so an exception should be thrown in that case indicating
> > > >> that a version column must be defined.
> > > >>
> > > >>
> > > >>
> > > >> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > >>
> > > >>
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [DAS] TUSCANY-866: Default OCC policy
Posted by Amita Vadhavkar <am...@gmail.com>.
Please let me know what is there in code base at present/in-progress for OCC
recovery? Will you please elaborate the approach and if there is any item I
can pick up for next release?
Regards,
Amita
On 10/18/06, Brent Daniel <br...@gmail.com> wrote:
>
> I've been working on some function to recover from collisions (since
> at the moment we have none :) ). One of the recovery mechanisms I'm
> planning to put in is a means to "force" the update. Though it would
> require an extra step, this should take care of this case.
>
> Brent
>
> On 10/17/06, Kevin Williams <ke...@qwest.net> wrote:
> > I have talked to clients that want their data slammed into the database
> > no matter what. But, this is an edge case. We can wait for someone to
> > ask for it ... or contribute it.
> >
> > Brent Daniel wrote:
> >
> > > Kevin,
> > >
> > > We can do that, but it will be our fourth different way to specify
> > > OCC behavior (default, version column, managed version column, and
> > > none.) Is there a good use case for this? It seems like the only time
> > > you would want to go without concurrency control is when you have
> > > read-only tables, and in that case this behavior would never be
> > > reached anyway.
> > >
> > > Brent
> > >
> > > On 10/17/06, Kevin Williams <ke...@qwest.net> wrote:
> > >
> > >> Brent,
> > >> This sounds reasonable but we probably want some mechanism to provide
> > >> our previous default policy which is "no collision checking". Maybe
> > >> a piece of config. What do you think?
> > >> --
> > >> Kevin
> > >>
> > >>
> > >>
> > >> [DAS] Use overqualified update by default
> > >> -----------------------------------------
> > >>
> > >> Key: TUSCANY-866
> > >> URL: http://issues.apache.org/jira/browse/TUSCANY-866
> > >> Project: Tuscany
> > >> Issue Type: New Feature
> > >> Components: Java DAS RDB
> > >> Reporter: Brent Daniel
> > >>
> > >>
> > >> Currently in the DAS we either use a user-defined version column or
> > >> do not use any concurrency control. We have enough information to
> > >> build an overqualified update in cases where a version column is not
> > >> defined. For example, if a field "name" is changed from "Bob" to
> > >> "John", we would generate a query such as:
> > >>
> > >> UPDATE CUSTOMER SET NAME = 'John' WHERE ID = 1 AND NAME = 'Bob'
> > >>
> > >> If the statement does not update any rows in the database, the DAS
> > >> will throw a concurrency control exception.
> > >>
> > >> This scheme will not work in case of LONG VARCHAR, BLOB, or CLOB
> > >> columns, so an exception should be thrown in that case indicating
> > >> that a version column must be defined.
> > >>
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >>
> > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > >
> > >
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: [DAS] TUSCANY-866: Default OCC policy
Posted by Brent Daniel <br...@gmail.com>.
I've been working on some function to recover from collisions (since
at the moment we have none :) ). One of the recovery mechanisms I'm
planning to put in is a means to "force" the update. Though it would
require an extra step, this should take care of this case.
Brent
On 10/17/06, Kevin Williams <ke...@qwest.net> wrote:
> I have talked to clients that want their data slammed into the database
> no matter what. But, this is an edge case. We can wait for someone to
> ask for it ... or contribute it.
>
> Brent Daniel wrote:
>
> > Kevin,
> >
> > We can do that, but it will be our fourth different way to specify
> > OCC behavior (default, version column, managed version column, and
> > none.) Is there a good use case for this? It seems like the only time
> > you would want to go without concurrency control is when you have
> > read-only tables, and in that case this behavior would never be
> > reached anyway.
> >
> > Brent
> >
> > On 10/17/06, Kevin Williams <ke...@qwest.net> wrote:
> >
> >> Brent,
> >> This sounds reasonable but we probably want some mechanism to provide
> >> our previous default policy which is "no collision checking". Maybe
> >> a piece of config. What do you think?
> >> --
> >> Kevin
> >>
> >>
> >>
> >> [DAS] Use overqualified update by default
> >> -----------------------------------------
> >>
> >> Key: TUSCANY-866
> >> URL: http://issues.apache.org/jira/browse/TUSCANY-866
> >> Project: Tuscany
> >> Issue Type: New Feature
> >> Components: Java DAS RDB
> >> Reporter: Brent Daniel
> >>
> >>
> >> Currently in the DAS we either use a user-defined version column or
> >> do not use any concurrency control. We have enough information to
> >> build an overqualified update in cases where a version column is not
> >> defined. For example, if a field "name" is changed from "Bob" to
> >> "John", we would generate a query such as:
> >>
> >> UPDATE CUSTOMER SET NAME = 'John' WHERE ID = 1 AND NAME = 'Bob'
> >>
> >> If the statement does not update any rows in the database, the DAS
> >> will throw a concurrency control exception.
> >>
> >> This scheme will not work in case of LONG VARCHAR, BLOB, or CLOB
> >> columns, so an exception should be thrown in that case indicating
> >> that a version column must be defined.
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [DAS] TUSCANY-866: Default OCC policy
Posted by Kevin Williams <ke...@qwest.net>.
I have talked to clients that want their data slammed into the database
no matter what. But, this is an edge case. We can wait for someone to
ask for it ... or contribute it.
Brent Daniel wrote:
> Kevin,
>
> We can do that, but it will be our fourth different way to specify
> OCC behavior (default, version column, managed version column, and
> none.) Is there a good use case for this? It seems like the only time
> you would want to go without concurrency control is when you have
> read-only tables, and in that case this behavior would never be
> reached anyway.
>
> Brent
>
> On 10/17/06, Kevin Williams <ke...@qwest.net> wrote:
>
>> Brent,
>> This sounds reasonable but we probably want some mechanism to provide
>> our previous default policy which is "no collision checking". Maybe
>> a piece of config. What do you think?
>> --
>> Kevin
>>
>>
>>
>> [DAS] Use overqualified update by default
>> -----------------------------------------
>>
>> Key: TUSCANY-866
>> URL: http://issues.apache.org/jira/browse/TUSCANY-866
>> Project: Tuscany
>> Issue Type: New Feature
>> Components: Java DAS RDB
>> Reporter: Brent Daniel
>>
>>
>> Currently in the DAS we either use a user-defined version column or
>> do not use any concurrency control. We have enough information to
>> build an overqualified update in cases where a version column is not
>> defined. For example, if a field "name" is changed from "Bob" to
>> "John", we would generate a query such as:
>>
>> UPDATE CUSTOMER SET NAME = 'John' WHERE ID = 1 AND NAME = 'Bob'
>>
>> If the statement does not update any rows in the database, the DAS
>> will throw a concurrency control exception.
>>
>> This scheme will not work in case of LONG VARCHAR, BLOB, or CLOB
>> columns, so an exception should be thrown in that case indicating
>> that a version column must be defined.
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [DAS] TUSCANY-866: Default OCC policy
Posted by Brent Daniel <br...@gmail.com>.
Kevin,
We can do that, but it will be our fourth different way to specify
OCC behavior (default, version column, managed version column, and
none.) Is there a good use case for this? It seems like the only time
you would want to go without concurrency control is when you have
read-only tables, and in that case this behavior would never be
reached anyway.
Brent
On 10/17/06, Kevin Williams <ke...@qwest.net> wrote:
> Brent,
> This sounds reasonable but we probably want some mechanism to provide our previous default policy which is "no collision checking". Maybe a piece of config. What do you think?
> --
> Kevin
>
>
>
> [DAS] Use overqualified update by default
> -----------------------------------------
>
> Key: TUSCANY-866
> URL: http://issues.apache.org/jira/browse/TUSCANY-866
> Project: Tuscany
> Issue Type: New Feature
> Components: Java DAS RDB
> Reporter: Brent Daniel
>
>
> Currently in the DAS we either use a user-defined version column or do not use any concurrency control. We have enough information to build an overqualified update in cases where a version column is not defined. For example, if a field "name" is changed from "Bob" to "John", we would generate a query such as:
>
> UPDATE CUSTOMER SET NAME = 'John' WHERE ID = 1 AND NAME = 'Bob'
>
> If the statement does not update any rows in the database, the DAS will throw a concurrency control exception.
>
> This scheme will not work in case of LONG VARCHAR, BLOB, or CLOB columns, so an exception should be thrown in that case indicating that a version column must be defined.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org