Re: synchronization problem

2008-03-31 Thread PENPEN

But I think the increment of the version column is the same with the
example of Poll I mentioned in the previous post.
If the transaction is not used, the read action is separated with the
write action by default. The problem still can happen.
Or do you have some special method to update this column? If so,
please teach me. Many thanks!

On Mar 31, 1:34 pm, meppum <[EMAIL PROTECTED]> wrote:
> I like the version column solution because it is more DB cross
> compatible. Some databases don't support the same sort of timestamp as
> others. But all DBs support integer columns. In terms of performance
> it's probably the same or close to it as the comparison is done on the
> database side.
>
> On Mar 31, 12:14 am, PENPEN <[EMAIL PROTECTED]> wrote:
>
> > I checked the transaction module of django. I think it could work.
> > But why do you prefer this version column solution? Does it have
> > better performance?
>
> > On 3月31日, 上午9时54分, meppum <[EMAIL PROTECTED]> wrote:
>
> > > I found this thread helpful.
>
> > >http://groups.google.com/group/django-users/browse_thread/thread/e9db...
>
> > > On Mar 30, 9:11 pm, Mark Green <[EMAIL PROTECTED]> wrote:
>
> > > > On Sun, 2008-03-30 at 17:49 -0700, meppum wrote:
> > > > > The easiest way to deal with this is to create a "version" column that
> > > > > gets updated with the current version number of the row in the
> > > > > database. Increment this column value each time a save is performed on
> > > > > that row. Override the save method on the model you want to perform
> > > > > this check on (in your example the poll model), and check on commit
> > > > > check that the value of the "version" colum in the database is LESS
> > > > > THEN the value of the "verson" column you are about to commit. If it
> > > > > is not, then throw an error. and rollback the transaction.
>
> > > > Ehm, and how would you "check on commit"?
>
> > > > -mark- Hide quoted text -
>
> > - Show quoted text -
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---



Re: synchronization problem

2008-03-30 Thread PENPEN

I checked the transaction module of django. I think it could work.
But why do you prefer this version column solution? Does it have
better performance?

On 3月31日, 上午9时54分, meppum <[EMAIL PROTECTED]> wrote:
> I found this thread helpful.
>
> http://groups.google.com/group/django-users/browse_thread/thread/e9db...
>
> On Mar 30, 9:11 pm, Mark Green <[EMAIL PROTECTED]> wrote:
>
> > On Sun, 2008-03-30 at 17:49 -0700, meppum wrote:
> > > The easiest way to deal with this is to create a "version" column that
> > > gets updated with the current version number of the row in the
> > > database. Increment this column value each time a save is performed on
> > > that row. Override the save method on the model you want to perform
> > > this check on (in your example the poll model), and check on commit
> > > check that the value of the "version" colum in the database is LESS
> > > THEN the value of the "verson" column you are about to commit. If it
> > > is not, then throw an error. and rollback the transaction.
>
> > Ehm, and how would you "check on commit"?
>
> > -mark
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---



Re: synchronization problem

2008-03-30 Thread Mark Green

On Sun, 2008-03-30 at 17:49 -0700, meppum wrote:
> The easiest way to deal with this is to create a "version" column that
> gets updated with the current version number of the row in the
> database. Increment this column value each time a save is performed on
> that row. Override the save method on the model you want to perform
> this check on (in your example the poll model), and check on commit
> check that the value of the "version" colum in the database is LESS
> THEN the value of the "verson" column you are about to commit. If it
> is not, then throw an error. and rollback the transaction.

Ehm, and how would you "check on commit"?


-mark



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---



Re: synchronization problem

2008-03-30 Thread Karen Tracey
On Sun, Mar 30, 2008 at 8:45 AM, PENPEN <[EMAIL PROTECTED]> wrote:

>
> Hi Carl,
> I didn't mention to the syncdb of manage.py.
> I'm talking about the problem that may happen when trying to access
> the db.
>
> Take a poll for exmaple. It may happen that 2 users vote at the same
> time. A vote action is made in the three steps:
> 1. read the old counter
> 2. add the counter by 1
> 3. save the counter
>
> I denote the two users as A and B, and A1 means the 1st step of A's
> progress, and B2 means the 2nd step of B, etc.
>
> I don't know how django deal with the requests of A and B. I suppose
> they are independent. So I think the scenario may happen like this:
> A1 B1 A2 A3 B2 B3
> or
> A1 A2 A3 B1 B2 B3
> or others
>
> If B1 happens after A3, there is no problem, and the counter is
> increased by 2. But if B1 is before A3, then B will read the old value
> again. And at last, the counter is only increased by 1, not 2.
>
> That's my concern. So how Django handle with such case? Many thanks!


Django allows you to hook into your database's underlying transaction
support:

http://www.djangoproject.com/documentation/transactions/

Karen

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---



Re: synchronization problem

2008-03-30 Thread PENPEN

Hi Carl,
I didn't mention to the syncdb of manage.py.
I'm talking about the problem that may happen when trying to access
the db.

Take a poll for exmaple. It may happen that 2 users vote at the same
time. A vote action is made in the three steps:
1. read the old counter
2. add the counter by 1
3. save the counter

I denote the two users as A and B, and A1 means the 1st step of A's
progress, and B2 means the 2nd step of B, etc.

I don't know how django deal with the requests of A and B. I suppose
they are independent. So I think the scenario may happen like this:
A1 B1 A2 A3 B2 B3
or
A1 A2 A3 B1 B2 B3
or others

If B1 happens after A3, there is no problem, and the counter is
increased by 2. But if B1 is before A3, then B will read the old value
again. And at last, the counter is only increased by 1, not 2.

That's my concern. So how Django handle with such case? Many thanks!

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---



Re: synchronization problem

2008-03-30 Thread Carl

Hi PenPen,

what do you mean with 'the multi-thread scenario'?
I assume you already know the syncdb param for the manage.py?

Best regards,

Carl

On 30 Mrz., 13:12, PENPEN <[EMAIL PROTECTED]> wrote:
> Does Django provide any method to handle the synchronization problems
> with DB? How does it keep the DB's consistency in the multi-thread
> scenario?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---