Proper multi-users design

#11

Quote:

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, ...)

Quote:

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.

Quote:

Are you planning on implementing on all of the current back ends?

Yes.

Quote:

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.

Quote:

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

#12

Quote:

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, ...)

Quote:

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.

Quote:

Are you planning on implementing on all of the current back ends?

Yes.

Quote:

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.

Quote:

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

#13

Quote:

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, ...)

Quote:

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.

Quote:

Are you planning on implementing on all of the current back ends?

Yes.

Quote:

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.

Quote:

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

#14

Quote:

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, ...)

Quote:

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.

Quote:

Are you planning on implementing on all of the current back ends?

Yes.

Quote:

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.

Quote:

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

#15

Quote:

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, ...)

Quote:

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.

Quote:

Are you planning on implementing on all of the current back ends?

Yes.

Quote:

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.

Quote:

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

#16

Quote:

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, ...)

Quote:

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.

Quote:

Are you planning on implementing on all of the current back ends?

Yes.

Quote:

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.

Quote:

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

#17

Quote:

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, ...)

Quote:

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.

Quote:

Are you planning on implementing on all of the current back ends?

Yes.

Quote:

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.

Quote:

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

#18

Quote:

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, ...)

Quote:

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.

Quote:

Are you planning on implementing on all of the current back ends?

Yes.

Quote:

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.

Quote:

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

#19

Quote:

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, ...)

Quote:

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.

Quote:

Are you planning on implementing on all of the current back ends?

Yes.

Quote:

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.

Quote:

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

#20

On Oct 15, 8:38*pm, Ael <a... (AT) adnx (DOT) net> wrote:

Quote:

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.