Serialized transaction question, revisited

Hi All,

Since I did not get any reply on the question I posted two days ago, I
decided to download the EM to understand how the serialized transactions
work.

I created a test table and populated it with a few records.

In one EM instance I started a transaction, and add a record.

In another EM instance I attempt to start a transaction or add another
record and a lock time out error occurs.

While the first transaction is active, it is not possible to modify the
table. No matter how multi-threaded and optimized the server is, in
multi-user environments this will be a bottleneck.

Is there any plan for the future to support concurrent transactions?

Thanks,

Michel

Michel <reply@onnewsgroup.com> wrote in news:3F5F26F7.3020104
@onnewsgroup.com:

> In another EM instance I attempt to start a transaction or add another
> record and a lock time out error occurs.
>
> While the first transaction is active, it is not possible to modify
the
> table. No matter how multi-threaded and optimized the server is, in
> multi-user environments this will be a bottleneck.


Hi Michel,

Transactions are only sopposed to be open for a fraction of a second,
having start transaction in EM is a bit of a design flaw realy, you
should never do this sort of thing in your own apps.

In your example you never needed to use the StartTransaction option, in
that case record locks would have been used instead.



> Is there any plan for the future to support concurrent transactions?

How would you sugest implementing serialization if you had concurrent
transactions on the same table?.

Explicit transactions are only required when you wish to keep data-
integrety,.

eg. If you wanted to update Table1 & Table2, but if neither table could
be updated, you would rollback and all changes would be discarded.


Keith..

Michel <reply@onnewsgroup.com> wrote in news:3F5F26F7.3020104
@onnewsgroup.com:

>
> Hi All,
>
> Since I did not get any reply on the question I posted two days ago, I
> decided to download the EM to understand how the serialized
transactions
> work.
>
> I created a test table and populated it with a few records.
>
> In one EM instance I started a transaction, and add a record.
>
> In another EM instance I attempt to start a transaction or add another
> record and a lock time out error occurs.
>
> While the first transaction is active, it is not possible to modify the
> table. No matter how multi-threaded and optimized the server is, in
> multi-user environments this will be a bottleneck.
>
> Is there any plan for the future to support concurrent transactions?
>
> Thanks,
>
> Michel
>
>

I agree with you the transaction engine should be improved, and support
concurrent transactions.

I understand that it won't be easy in the short/medium time

Roberto

Roberto Nicchi wrote:
> I agree with you the transaction engine should be improved, and support
> concurrent transactions.

How is a concurrent transaction supposed to work? Suppose client 1
starts a transaction and then client 2 starts a transaction on the same
table. Client 1 changes a record, posts, and commits. Now the tables are
different than they were when client 2 started his transaction. What is
supposed to happen to client 2?

--
David Marcus

David Marcus <davidmarcus@alum.mit.edu> wrote in
news:MPG.19c90768e5c493199897b1@news.nexusdb.com:

> Roberto Nicchi wrote:
>> I agree with you the transaction engine should be improved, and support
>> concurrent transactions.
>
> How is a concurrent transaction supposed to work? Suppose client 1
> starts a transaction and then client 2 starts a transaction on the same
> table. Client 1 changes a record, posts, and commits. Now the tables are
> different than they were when client 2 started his transaction. What is
> supposed to happen to client 2?
>

I don't see the problem is client 2 is updating a different record....
Transction should lock only the records changed.

If clients are updating the same records, client1 (the first that started
the transaction) should allows to complete the transaction. Client 2 should
wait until client 1 transaction is not finished. If client 1 transaction is
too long client 2 should get a timeout error.

easy

Roberto

> If clients are updating the same records, client1 (the first that started
> the transaction) should allows to complete the transaction. Client 2
should
> wait until client 1 transaction is not finished. If client 1 transaction
is
> too long client 2 should get a timeout error.

So, if a record changes in the first transaction, its ok for the second
transaction to overwrite it?

--


Eivind Bakkestuen [NDD]
Please, no email unless requested.
Search Borland and third-party newsgroups here: www.tamaracka.com

"Eivind Bakkestuen [NDD]" <Ieivind.bakkestuenHATE@nexusdb.comSPAM> wrote
in news:3f5f4fda$1@wic040d.:

>> If clients are updating the same records, client1 (the first that
>> started the transaction) should allows to complete the transaction.
>> Client 2
> should
>> wait until client 1 transaction is not finished. If client 1
>> transaction
> is
>> too long client 2 should get a timeout error.
>
> So, if a record changes in the first transaction, its ok for the
> second transaction to overwrite it?
>

in this logic ... yes

Roberto

If you have no need to protect the integrity of your data, you don't need
transactions at all. <BG>

--


Eivind Bakkestuen [NDD]
Please, no email unless requested.
Search Borland and third-party newsgroups here: www.tamaracka.com


"Roberto Nicchi" <software@masterinformatica.net> wrote in message
> >
> > So, if a record changes in the first transaction, its ok for the
> > second transaction to overwrite it?
> >
>
> in this logic ... yes
>

"Eivind Bakkestuen [NDD]" <Ieivind.bakkestuenHATE@nexusdb.comSPAM> wrote in
news:3f5f5714$1@wic040d.:

> If you have no need to protect the integrity of your data, you don't need
> transactions at all. <BG>
>

another idea:

client 1 start transaction
cliente 1 change/add some recors in some tables
client2 start transaction
client 2 change/add same records in some tables
if client 2 edit the same records that are already in an existing
transaction should wait until the current transaction is finished (or
timeout if current transaction is too long)

Roberto

Roberto Nicchi wrote:
> client 1 start transaction
> cliente 1 change/add some recors in some tables
> client2 start transaction
> client 2 change/add same records in some tables
> if client 2 edit the same records that are already in an existing
> transaction should wait until the current transaction is finished (or
> timeout if current transaction is too long)

And what happens when the current transaction is finished? Does Client 2
find out that client 1 changed the records while client 2 wasn't
looking?

Seems to me what you want is some way to lock specific records and then
have the transaction only change those records. If you can't acquire the
locks, then the transaction won't start.

--
David Marcus