 | |
#1
 
| |||
| |||
|
Distributed Transactions -
03-31-2008
, 06:36 AM
#2
| |||
| |||
|
|
Hi, I am new to the field so I apologize if this question seems trivial. I am currently working on distributed software transactional memory (STM). Since database transactions are the semantic inspiration for STM, I was wondering about the level of concurrency of distributed database transactions. Specifically, are subtransactions concurrent or are they sequential? If they are sequential, doesn't this prolong the duration of the transaction and hence increase the chances of conflicts and hence retries? Has this problem, possible "retry thrashing", if you will, been considered in the literature? Again I apologize if this question seems trivial, but I am relatively new to the field. How sweet...Rediscovery that concurrency is better handled at database |
talking about reinventing square wheels...
Concurrency handling (serialization) is purely platform dependent.
You will not have the same rules if you are using ORACLE SQL Server or
DB2. Most transactional concurrency mechanisms are much more complex
than a simplystic serialized/concurrent dichotomy.
#3
| |||
| |||
|
|
Hi, I am new to the field so I apologize if this question seems trivial. I am currently working on distributed software transactional memory (STM). Since database transactions are the semantic inspiration for STM, I was wondering about the level of concurrency of distributed database transactions. Specifically, are subtransactions concurrent or are they sequential? If they are sequential, doesn't this prolong the duration of the transaction and hence increase the chances of conflicts and hence retries? Has this problem, possible "retry thrashing", if you will, been considered in the literature? Again I apologize if this question seems trivial, but I am relatively new to the field. How sweet...Rediscovery that concurrency is better handled at database |
talking about reinventing square wheels...
Concurrency handling (serialization) is purely platform dependent.
You will not have the same rules if you are using ORACLE SQL Server or
DB2. Most transactional concurrency mechanisms are much more complex
than a simplystic serialized/concurrent dichotomy.
#4
| |||
| |||
|
|
Hi, I am new to the field so I apologize if this question seems trivial. I am currently working on distributed software transactional memory (STM). Since database transactions are the semantic inspiration for STM, I was wondering about the level of concurrency of distributed database transactions. Specifically, are subtransactions concurrent or are they sequential? If they are sequential, doesn't this prolong the duration of the transaction and hence increase the chances of conflicts and hence retries? Has this problem, possible "retry thrashing", if you will, been considered in the literature? Again I apologize if this question seems trivial, but I am relatively new to the field. How sweet...Rediscovery that concurrency is better handled at database |
talking about reinventing square wheels...
Concurrency handling (serialization) is purely platform dependent.
You will not have the same rules if you are using ORACLE SQL Server or
DB2. Most transactional concurrency mechanisms are much more complex
than a simplystic serialized/concurrent dichotomy.
#5
| |||
| |||
|
|
Hi, I am new to the field so I apologize if this question seems trivial. I am currently working on distributed software transactional memory (STM). Since database transactions are the semantic inspiration for STM, I was wondering about the level of concurrency of distributed database transactions. Specifically, are subtransactions concurrent or are they sequential? If they are sequential, doesn't this prolong the duration of the transaction and hence increase the chances of conflicts and hence retries? Has this problem, possible "retry thrashing", if you will, been considered in the literature? Again I apologize if this question seems trivial, but I am relatively new to the field. How sweet...Rediscovery that concurrency is better handled at database |
talking about reinventing square wheels...
Concurrency handling (serialization) is purely platform dependent.
You will not have the same rules if you are using ORACLE SQL Server or
DB2. Most transactional concurrency mechanisms are much more complex
than a simplystic serialized/concurrent dichotomy.
#6
| |||
| |||
|
|
Hi, I am new to the field so I apologize if this question seems trivial. I am currently working on distributed software transactional memory (STM). Since database transactions are the semantic inspiration for STM, I was wondering about the level of concurrency of distributed database transactions. Specifically, are subtransactions concurrent or are they sequential? If they are sequential, doesn't this prolong the duration of the transaction and hence increase the chances of conflicts and hence retries? Has this problem, possible "retry thrashing", if you will, been considered in the literature? Again I apologize if this question seems trivial, but I am relatively new to the field. How sweet...Rediscovery that concurrency is better handled at database |
talking about reinventing square wheels...
Concurrency handling (serialization) is purely platform dependent.
You will not have the same rules if you are using ORACLE SQL Server or
DB2. Most transactional concurrency mechanisms are much more complex
than a simplystic serialized/concurrent dichotomy.
#7
| |||
| |||
|
|
Hi, I am new to the field so I apologize if this question seems trivial. I am currently working on distributed software transactional memory (STM). Since database transactions are the semantic inspiration for STM, I was wondering about the level of concurrency of distributed database transactions. Specifically, are subtransactions concurrent or are they sequential? If they are sequential, doesn't this prolong the duration of the transaction and hence increase the chances of conflicts and hence retries? Has this problem, possible "retry thrashing", if you will, been considered in the literature? Again I apologize if this question seems trivial, but I am relatively new to the field. How sweet...Rediscovery that concurrency is better handled at database |
talking about reinventing square wheels...
Concurrency handling (serialization) is purely platform dependent.
You will not have the same rules if you are using ORACLE SQL Server or
DB2. Most transactional concurrency mechanisms are much more complex
than a simplystic serialized/concurrent dichotomy.
#8
| |||
| |||
|
|
Hi, I am new to the field so I apologize if this question seems trivial. I am currently working on distributed software transactional memory (STM). Since database transactions are the semantic inspiration for STM, I was wondering about the level of concurrency of distributed database transactions. Specifically, are subtransactions concurrent or are they sequential? If they are sequential, doesn't this prolong the duration of the transaction and hence increase the chances of conflicts and hence retries? Has this problem, possible "retry thrashing", if you will, been considered in the literature? Again I apologize if this question seems trivial, but I am relatively new to the field. How sweet...Rediscovery that concurrency is better handled at database |
talking about reinventing square wheels...
Concurrency handling (serialization) is purely platform dependent.
You will not have the same rules if you are using ORACLE SQL Server or
DB2. Most transactional concurrency mechanisms are much more complex
than a simplystic serialized/concurrent dichotomy.
#9
| |||
| |||
|
|
Hi, I am new to the field so I apologize if this question seems trivial. I am currently working on distributed software transactional memory (STM). Since database transactions are the semantic inspiration for STM, I was wondering about the level of concurrency of distributed database transactions. Specifically, are subtransactions concurrent or are they sequential? If they are sequential, doesn't this prolong the duration of the transaction and hence increase the chances of conflicts and hence retries? Has this problem, possible "retry thrashing", if you will, been considered in the literature? Again I apologize if this question seems trivial, but I am relatively new to the field. How sweet...Rediscovery that concurrency is better handled at database |
talking about reinventing square wheels...
Concurrency handling (serialization) is purely platform dependent.
You will not have the same rules if you are using ORACLE SQL Server or
DB2. Most transactional concurrency mechanisms are much more complex
than a simplystic serialized/concurrent dichotomy.
#10
| |||
| |||
|
|
Hi, I am new to the field so I apologize if this question seems trivial. I am currently working on distributed software transactional memory (STM). Since database transactions are the semantic inspiration for STM, I was wondering about the level of concurrency of distributed database transactions. Specifically, are subtransactions concurrent or are they sequential? If they are sequential, doesn't this prolong the duration of the transaction and hence increase the chances of conflicts and hence retries? Has this problem, possible "retry thrashing", if you will, been considered in the literature? Again I apologize if this question seems trivial, but I am relatively new to the field. How sweet...Rediscovery that concurrency is better handled at database |
talking about reinventing square wheels...
Concurrency handling (serialization) is purely platform dependent.
You will not have the same rules if you are using ORACLE SQL Server or
DB2. Most transactional concurrency mechanisms are much more complex
than a simplystic serialized/concurrent dichotomy.
 |
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.