Menu
▾
▴
cubridcluster-devs
|
From: cubridcluster <no...@so...> - 2010-12-03 05:40:23
|
#308: [Task]Support TRANSACTION ISOLATION and LOCK TIMEOUT setting in the global
transcation
--------------------------+-------------------------------------------------
Reporter: miaoyu | Owner: miaoyu
Type: task | Status: new
Priority: major | Milestone: M2 - distributed partition
Component: cubrid (all) | Version: Cluster 2010 R1
Severity: unclear | Keywords: #220 Global Transaction
--------------------------+-------------------------------------------------
Support TRANSACTION ISOLATION and LOCK TIMEOUT setting in the global
transcation
--
Ticket URL: <http://sourceforge.net/apps/trac/cubridcluster/ticket/308>
cubridcluster <http://sourceforge.net/projects/cubridcluster/>
SF-project cubridcluster
|
|
From: cubridcluster <no...@so...> - 2010-12-03 05:42:01
|
#308: [Task]Support TRANSACTION ISOLATION and LOCK TIMEOUT setting in the global
transcation
--------------------------+-------------------------------------------------
Reporter: miaoyu | Owner: miaoyu
Type: task | Status: new
Priority: major | Milestone: M2 - distributed partition
Component: cubrid (all) | Version: Cluster 2010 R1
Severity: unclear | Keywords: #220 Global Transaction
--------------------------+-------------------------------------------------
Description changed by miaoyu:
Old description:
> Support TRANSACTION ISOLATION and LOCK TIMEOUT setting in the global
> transcation
New description:
Support TRANSACTION ISOLATION and LOCK TIMEOUT setting in the global
transcation.
Function Description:
The TRANSACTION ISOLATION LEVEL and LOCK TIMEOUT feature is implmented in
the server.
The client only sets the option to its current transaction, and then lock
manager in the server gets the setting
from the transaction descriptor and then controls lock requets using those
setting.
Thus, I think that no change is required in our the Cluster system.
The client will send the request messages of
NET_SERVER_LOG_RESET_WAITSECS/NET_SERVER_LOG_RESET_ISOLATION
to the connected server S1 then the S1 will set its own LOG_TDES
structure. (Until now, same with the local case.)
If the transaction in the S1 is associated with the other servers due to
global query / remote scan / global schema
and so on, (it can be identified by whether has global_tranid or not.)
then the S1 sends the same request
to the assoicated servers. If the transaction is not associated yet, then
the request can be sent at the first time
when it talks to the other server.
--
--
Ticket URL: <http://sourceforge.net/apps/trac/cubridcluster/ticket/308#comment:1>
cubridcluster <http://sourceforge.net/projects/cubridcluster/>
SF-project cubridcluster
|
|
From: cubridcluster <no...@so...> - 2010-12-03 05:43:45
|
#308: [Task]Support TRANSACTION ISOLATION and LOCK TIMEOUT setting in the global
transcation
--------------------------+-------------------------------------------------
Reporter: miaoyu | Owner: miaoyu
Type: task | Status: new
Priority: major | Milestone: M2 - distributed partition
Component: cubrid (all) | Version: Cluster 2010 R1
Severity: unclear | Keywords: #220 Global Transaction
--------------------------+-------------------------------------------------
Description changed by miaoyu:
Old description:
> Support TRANSACTION ISOLATION and LOCK TIMEOUT setting in the global
> transcation.
>
> Function Description:
>
> The TRANSACTION ISOLATION LEVEL and LOCK TIMEOUT feature is implmented in
> the server.
> The client only sets the option to its current transaction, and then lock
> manager in the server gets the setting
> from the transaction descriptor and then controls lock requets using
> those setting.
> Thus, I think that no change is required in our the Cluster system.
> The client will send the request messages of
> NET_SERVER_LOG_RESET_WAITSECS/NET_SERVER_LOG_RESET_ISOLATION
> to the connected server S1 then the S1 will set its own LOG_TDES
> structure. (Until now, same with the local case.)
> If the transaction in the S1 is associated with the other servers due to
> global query / remote scan / global schema
> and so on, (it can be identified by whether has global_tranid or not.)
> then the S1 sends the same request
> to the assoicated servers. If the transaction is not associated yet, then
> the request can be sent at the first time
> when it talks to the other server.
New description:
Support TRANSACTION ISOLATION and LOCK TIMEOUT setting in the global
transcation.
Function Description (from iamyaw):
The TRANSACTION ISOLATION LEVEL and LOCK TIMEOUT feature is implmented in
the server.
The client only sets the option to its current transaction, and then lock
manager in the server gets the setting from the transaction descriptor and
then controls lock requets using those setting.
Thus, I think that no change is required in our the Cluster system.
The client will send the request messages of
NET_SERVER_LOG_RESET_WAITSECS/NET_SERVER_LOG_RESET_ISOLATION
to the connected server S1 then the S1 will set its own LOG_TDES
structure. (Until now, same with the local case.)
If the transaction in the S1 is associated with the other servers due to
global query / remote scan / global schema and so on, (it can be
identified by whether has global_tranid or not.) then the S1 sends the
same request to the assoicated servers. If the transaction is not
associated yet, then the request can be sent at the first time
when it talks to the other server.
--
--
Ticket URL: <http://sourceforge.net/apps/trac/cubridcluster/ticket/308#comment:2>
cubridcluster <http://sourceforge.net/projects/cubridcluster/>
SF-project cubridcluster
|
|
From: cubridcluster <no...@so...> - 2010-12-29 11:07:50
|
#308: [Task]Support TRANSACTION ISOLATION and LOCK TIMEOUT setting in the global
transcation
--------------------------+-------------------------------------------------
Reporter: miaoyu | Owner: miaoyu
Type: task | Status: new
Priority: major | Milestone: M3 - load balancing
Component: cubrid (all) | Version: Cluster 2010 R1
Severity: unclear | Keywords: #220 Global Transaction
--------------------------+-------------------------------------------------
Changes (by xiaoshan78):
* milestone: M2 - distributed partition => M3 - load balancing
--
Ticket URL: <http://sourceforge.net/apps/trac/cubridcluster/ticket/308#comment:3>
cubridcluster <http://sourceforge.net/projects/cubridcluster/>
SF-project cubridcluster
|
|
From: cubridcluster <no...@so...> - 2011-04-13 09:57:22
|
#308: [Task]Support TRANSACTION ISOLATION and LOCK TIMEOUT setting in the global
transcation
--------------------------+-------------------------------------------------
Reporter: miaoyu | Owner: cubridcluster-triage
Type: task | Status: assigned
Priority: major | Milestone: M3 - beta
Component: cubrid (all) | Version: Cluster 2010 R1
Severity: unclear | Keywords: #220 Global Transaction
--------------------------+-------------------------------------------------
Changes (by miaoyu):
* owner: miaoyu => cubridcluster-triage
* status: new => assigned
Comment:
This ticket is same with #469 [Task]
Set_global_isolation_lavel_and_timeout
It could be closed.
--
Ticket URL: <http://sourceforge.net/apps/trac/cubridcluster/ticket/308#comment:4>
cubridcluster <http://sourceforge.net/projects/cubridcluster/>
SF-project cubridcluster
|
|
From: cubridcluster <no...@so...> - 2011-06-14 05:10:37
|
#308: [Task]Support TRANSACTION ISOLATION and LOCK TIMEOUT setting in the global
transcation
-------------------------------------+--------------------------------------
Reporter: miaoyu | Owner: cubridcluster-triage
Type: task | Status: closed
Priority: major | Milestone: M3 - beta
Component: cubrid (all) | Version: Cluster 2010 R1
Severity: unclear | Resolution: duplicate
Keywords: #220 Global Transaction |
-------------------------------------+--------------------------------------
Changes (by dong1):
* status: assigned => closed
* resolution: => duplicate
--
Ticket URL: <http://sourceforge.net/apps/trac/cubridcluster/ticket/308#comment:5>
cubridcluster <http://sourceforge.net/projects/cubridcluster/>
SF-project cubridcluster
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X