 |
|
|
|
Next: filter a form with a query
|
| Author |
Message |
External
Since: Oct 15, 2008
Posts: 2
|
(Msg. 1) Posted: Wed Oct 15, 2008 9:27 am
Post subject: Proper multi-users design
Archived from groups: comp>databases>theory (more info?)
|
|
|
Hello,
I've inherited a single user application using a database (multiple
backends : Postgres, Firebird, Oracle) and need to bring it on par for
multi-users access.
Right now each DB operation (fetch a structure, update a record, ...) is
embedded in its own transaction, and I'm not really sure where to begin.
I'm not really looking for a specific DBMS procedure (that I can figure out
myself), but more for a generic best practices/how-to implementing proper
multi-users access.
I've searched a bit, but apart from the generic optimistic/pessim. locking
mechanisms available and transaction isolation did not find anything
worthwhile. Is my best bet to rework everything to _really_ use
transactions ?
Do you have any links, articles or books to recommend ?
Thanks in advance,
--
Ael |
|
| Back to top |
|
 | |
External
Since: Aug 01, 2008
Posts: 42
|
(Msg. 2) Posted: Wed Oct 15, 2008 10:26 am
Post subject: Re: Proper multi-users design [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)
|
|
|
"Ael" wrote in message
> Hello,
>
> I've inherited a single user application using a database (multiple
> backends : Postgres, Firebird, Oracle) and need to bring it on par for
> multi-users access.
>
> Right now each DB operation (fetch a structure, update a record, ...) is
> embedded in its own transaction, and I'm not really sure where to begin.
>
> I'm not really looking for a specific DBMS procedure (that I can figure
> out
> myself), but more for a generic best practices/how-to implementing proper
> multi-users access.
>
> I've searched a bit, but apart from the generic optimistic/pessim. locking
> mechanisms available and transaction isolation did not find anything
> worthwhile. Is my best bet to rework everything to _really_ use
> transactions ?
>
> Do you have any links, articles or books to recommend ?
>
> Thanks in advance,
>
Where are you starting from? Do you know what the acronym ACID stands for
with regard to transaction management and concurrency control? Do you have
the information needed to determine what the minimal binding between actions
and transactions must be in each of your applications? Are you planning on
implementing on all of the current back ends? Do you know how to cope with
concurrency, deadlock, and bottleneck issues in each of those back ends?
Your task could be pretty straightforward, or monumental, depending on the
specific situation. |
|
| Back to top |
|
| |
External
Since: Jan 22, 2008
Posts: 177
|
(Msg. 3) Posted: Thu Oct 16, 2008 4:35 am
Post subject: Re: Proper multi-users design [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)
|
|
|
On Oct 15, 8:38 pm, Ael wrote:
> Hello,
>
> I've inherited a single user application using a database (multiple
> backends : Postgres, Firebird, Oracle) and need to bring it on par for
> multi-users access.
>
> Right now each DB operation (fetch a structure, update a record, ...) is
> embedded in its own transaction, and I'm not really sure where to begin.
>
> I'm not really looking for a specific DBMS procedure (that I can figure out
> myself), but more for a generic best practices/how-to implementing proper
> multi-users access.
>
> I've searched a bit, but apart from the generic optimistic/pessim. locking
> mechanisms available and transaction isolation did not find anything
> worthwhile. Is my best bet to rework everything to _really_ use
> transactions ?
>
> Do you have any links, articles or books to recommend ?
>
> Thanks in advance,
>
> --
> Ael
Is distributed atomicity of updates required? Avoid that if you can. >> Stay informed about: Proper multi-users design |
|
| Back to top |
|
| |
External
Since: Oct 15, 2008
Posts: 2
|
(Msg. 4) Posted: Thu Oct 16, 2008 5:25 am
Post subject: Re: Proper multi-users design [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)
|
|
|
> Do you know what the acronym ACID stands for
> with regard to transaction management and concurrency control?
I do. Fortunately the database design I'm working on is pretty sane (3NF, in
production use for a few years with no major hiccup, relatively small :
~100 tables, ...)
> Do you have the information needed to determine what the minimal binding
> between actions and transactions must be in each of your applications?
I'm currently mapping them.
> Are you planning on implementing on all of the current back ends?
Yes.
> Do you know how to cope with concurrency, deadlock, and bottleneck issues
> in each of those back ends?
I've already had to deal with a few bottleneck issues, but I'm afraid I have
no previous experience with database concurrency.
> Your task could be pretty straightforward, or monumental, depending on the
> specific situation.
Well I'm taking it one step at a time. Thanks for your input, things are a
bit clearer.
--
Ael >> Stay informed about: Proper multi-users design |
|
| Back to top |
|
| |
| Related Topics: | Defining proper relationships between similar entities - Consider a scenario in which various users must be stored in a relational database. Said users have different access levels. In addition, each type of user has different information associated with their account. Here's an example: Customer { Username...
Multi Core hardware and the RDBMS - Haven't seen the topic, so here goes. What adverse impact can be seen to the future of the Relational/SQL database from the implications of multi-core chips and the resulting parallelism? I've only just begun to chew on the question, but from the..
Data modeling for a multi-company product - One feature of some ERP and other software application systems is the ability for the customer site to indicate in the setup which attributes are required and which are not related to the various data entry "screens." So, customer A might cons...
two db: is possible to limit the access of the users? - if I have two databases, is possible to limit the access of one user only at the own db and to avoid, for example, if it use a sql injection can in some way from its db to modify the other? so at max it can only damage its database. which setting is..
Design question - Hi all, not sure this is right group. Hoping someone could give me so advice on my database design. What is the best way to join these tables Short version goes like this.... I have tables : Person or Employee, Dependent (person is fk in dep table) .... |
|
You can post new topics in this forum
You can reply to topics in this forum
You can edit your posts in this forum
You can delete your posts in this forum
You can vote in polls in this forum
|
|
|
|
|
|
|
FAQ
Search
Profile
Private Messages
Log in
