Start transaction from base transaction

classic Classic list List threaded Threaded
86 messages Options
12345
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Parallel execution

Dimitry Sibiryakov-3
20.04.2017 15:49, Leyne, Sean wrote:
> "select f from t1 union select f from t2" is ONE statement with 2 parts!
>
> "Attachment" refers to the connection between a client and the server, it does not imply anything about how the engine might decompose a statement or how the parts could/would be executed!

   It doesn't matter. If both parts are executed simultaneously, from technical POV they
have no difference from independent queries executed simultaneously in one attachment and
transaction.


--
   WBR, SD.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Parallel execution

Dimitry Sibiryakov-3
In reply to this post by Vlad Khorsun-2
20.04.2017 16:20, Vlad Khorsun wrote:
>> even in the simplest cases like "select f from t1 union select f from t2"?
>    This case nor simplest nor better for parallel execution than "ordinary" "select * from t".

   Union used to produce plan SORT (T1 NATURAL), SORT(T2 NATURAL). Both record streams can
be fetched and sorted in parallel and then merged, right? And because of selects from
different tables, they won't race on data pages.


--
   WBR, SD.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Parallel execution

Vlad Khorsun-2
20.04.2017 17:50, Dimitry Sibiryakov wrote:
> 20.04.2017 16:20, Vlad Khorsun wrote:
>>> even in the simplest cases like "select f from t1 union select f from t2"?
>>     This case nor simplest nor better for parallel execution than "ordinary" "select * from t".
>
>     Union used to produce plan SORT (T1 NATURAL), SORT(T2 NATURAL). Both record streams can
> be fetched and sorted in parallel and then merged, right? And because of selects from
> different tables, they won't race on data pages.

   No. This is very naive view on parallel query execution. Real implementations works
differently. There is a lot of info in the net about it.

Vlad


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[SPAM] Re: Start transaction from base transaction

Vlad Khorsun-2
In reply to this post by Molnár Attila
20.04.2017 10:12, Molnár Attila wrote:
> +1 for this feature. I would be very happy for this. Also it would be
> awesmone if this consistent view were accessible later in time (this
> woudl mean garbage collection blocking).

   Blocking of GC is the easiest part of this task. One need also to preserve
metadata that was valid at interesting moment of time. Also it is necessary
to teach engine to use that metadata (instead of current one) within attachment
working "in the past". To do it it is necessary to make "snapshot" of that
metadata and save it with an interesting moment. And this is still just tip
of the iceberg, i suspect...

Regards,
Vlad

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [SPAM] Re: Start transaction from base transaction

Adriano dos Santos Fernandes-3
Em 20/04/2017 17:53, Vlad Khorsun escreveu:
> Also it is necessary
> to teach engine to use that metadata (instead of current one) within attachment
> working "in the past".
>

I'm doing a prototype implementation of this for active transactions,
i.e., the things I mentioned in this thread start.

I've it starting working, but implementation is very simple, weak and
almost non-tested at the moment.


Adriano

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [SPAM] Re: Start transaction from base transaction

Molnár Attila
Awesome! :)

On 2017.04.21. 1:30, Adriano dos Santos Fernandes wrote:

> Em 20/04/2017 17:53, Vlad Khorsun escreveu:
>> Also it is necessary
>> to teach engine to use that metadata (instead of current one) within attachment
>> working "in the past".
>>
> I'm doing a prototype implementation of this for active transactions,
> i.e., the things I mentioned in this thread start.
>
> I've it starting working, but implementation is very simple, weak and
> almost non-tested at the moment.
>
>
> Adriano
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Start transaction from base transaction

Adriano dos Santos Fernandes-3
Vlad and others,

Can you look at this?

https://github.com/asfernandes/firebird/tree/work/sharing-snapshot

It uses the simplest possible (and bad) IPC mechanism to manually test
the idea of get the snapshot from others processes.

It uses syntax: SET TRANSACTION SHARING SNAPSHOT FROM <base transaction
number>

It is working in my tests.

Not talking about the IPC mechanism, is there any other trick needed?


Adriano


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Start transaction from base transaction

Vlad Khorsun-2
05.05.2017 18:59, Adriano dos Santos Fernandes write:
> Vlad and others,
>
> Can you look at this?
>
> https://github.com/asfernandes/firebird/tree/work/sharing-snapshot

   I took a quick look, so don't get me too serious. Also, my opinion could be
incomplete and be changed later :)

> It uses the simplest possible (and bad) IPC mechanism to manually test
> the idea of get the snapshot from others processes.

   Yes, IPC\locking is a weak point (so far)

> It uses syntax: SET TRANSACTION SHARING SNAPSHOT FROM <base transaction
> number>

   It doesn't forces (nor expresses) new transaction isolation level to be SNAPSHOT.
Probably, it would be more natural to extend "snap_shot" rule in parser:

iso_mode
        : snap_shot
        | READ UNCOMMITTED version_mode
        | READ COMMITTED version_mode
        ;

%type <uintVal> snap_shot
snap_shot
        : SNAPSHOT
        | SNAPSHOT TABLE
        | SNAPSHOT TABLE STABILITY
+ | SNAPSHOT SHARING FROM <N>

   Also, transaction_options() should verify\enforce isc_tpb_concurrency isolation
level for a new transaction.

> It is working in my tests.
>
> Not talking about the IPC mechanism, is there any other trick needed?

   Ok, lets leave IPC\locking in peace for a while ;)

   I don't understand for what purpose tra_oldest_snapshot was added.
Also it is not clear why "base_number" variable is introduced in transaction_start()
and why it replaces "number" in many places.

   As for the tricks - so far i see no needs in something additional.
If we will decide to implement Sean's syntax with explicit "export" of transaction
snapshot, it could require some, though.

   Of course, IPC\locking should be reworked, but we agreed to not discuss it
at this stage.

Hope it helps,
Vlad

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Start transaction from base transaction

Adriano dos Santos Fernandes-3
On 05/05/2017 14:01, Vlad Khorsun wrote:
>
>    It doesn't forces (nor expresses) new transaction isolation level to be SNAPSHOT.

Yes, I forgot to inform it in comment for now.


> Probably, it would be more natural to extend "snap_shot" rule in parser:
>
> iso_mode
> : snap_shot
> | READ UNCOMMITTED version_mode
> | READ COMMITTED version_mode
> ;
>
> %type <uintVal> snap_shot
> snap_shot
> : SNAPSHOT
> | SNAPSHOT TABLE
> | SNAPSHOT TABLE STABILITY
> + | SNAPSHOT SHARING FROM <N>

I like it.


>    Also, transaction_options() should verify\enforce isc_tpb_concurrency isolation
> level for a new transaction.

Yes.


>    I don't understand for what purpose tra_oldest_snapshot was added.
In my understand, it's a property that new transaction should copy from
the base transaction. Isn't it?

Should I let the original code assign it even for new transactions
that's sharing a snapshot?

But please read answear bellow, may be important for it.


> Also it is not clear why "base_number" variable is introduced in transaction_start()
> and why it replaces "number" in many places.

When first normal (not with sharing snapshot option) transaction is
started, it must record others transaction snapshot until its own *number*.

When second (with sharing snapshot option) transaction is started,
*number* has its new number too, but the snapshot vector must be record
only to the *base_number*, i.e., its snapshot vector should be identical
to the first transaction.


Adriano


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Start transaction from base transaction

Dmitry Yemanov-3
In reply to this post by Vlad Khorsun-2
05.05.2017 20:01, Vlad Khorsun wrote:
>
> %type <uintVal> snap_shot
> snap_shot
> : SNAPSHOT
> | SNAPSHOT TABLE
> | SNAPSHOT TABLE STABILITY
> + | SNAPSHOT SHARING FROM <N>

SNAPSHOT BASED ON <N>
?


Dmitry


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Start transaction from base transaction

Adriano dos Santos Fernandes-3
On 05/05/2017 14:43, Dmitry Yemanov wrote:

> 05.05.2017 20:01, Vlad Khorsun wrote:
>> %type <uintVal> snap_shot
>> snap_shot
>> : SNAPSHOT
>> | SNAPSHOT TABLE
>> | SNAPSHOT TABLE STABILITY
>> + | SNAPSHOT SHARING FROM <N>
> SNAPSHOT BASED ON <N>
> ?
>
Do you think with this words it's clear that the new transaction uses
the same snapshot used in <N>, instead of incorrectly saying that it
will use <N> as the snapshot for the new transaction?

Thinking in these terms, I'm more inclined to adapt (renaming SHARING to
SHARED) Vlad's syntax to:

SET TRANSACTION ISOLATION LEVEL SNAPSHOT SHARED FROM <N>


Adriano


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Start transaction from base transaction

Vlad Khorsun-2
In reply to this post by Adriano dos Santos Fernandes-3
05.05.2017 20:36, Adriano dos Santos Fernandes wrote:
> On 05/05/2017 14:01, Vlad Khorsun :

...

>>     I don't understand for what purpose tra_oldest_snapshot was added.
> In my understand, it's a property that new transaction should copy from
> the base transaction. Isn't it?

   No. Re-evaluated value of OST is stored at jrd_trans::tra_oldest_active.

> Should I let the original code assign it even for new transactions
> that's sharing a snapshot?

   No.

> But please read answear bellow, may be important for it.
>
>
>> Also it is not clear why "base_number" variable is introduced in transaction_start()
>> and why it replaces "number" in many places.
>
> When first normal (not with sharing snapshot option) transaction is
> started, it must record others transaction snapshot until its own *number*.
>
> When second (with sharing snapshot option) transaction is started,
> *number* has its new number too, but the snapshot vector must be record
> only to the *base_number*, i.e., its snapshot vector should be identical
> to the first transaction.

   If you worry about high bound of transaction's copy of TIP (tra_transactions) -
it is already stored at jrd_trans::tra_top.

   BTW, transaction should export own snapshot at the end of transaction_start(),
because it is the moment when all it fields got actual values (especially
tra_oldest_active).

   Probably, transaction which import snapshot, should avoid recalculation of
OIT and OST. At least, it should not update own tra_oldest_active with new
value of OST.

Regards,
Vlad

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Start transaction from base transaction

Vlad Khorsun-2
In reply to this post by Adriano dos Santos Fernandes-3
05.05.2017 21:10, Adriano dos Santos Fernandes wrote:

> On 05/05/2017 14:43, Dmitry Yemanov wrote:
>> 05.05.2017 20:01, Vlad Khorsun wrote:
>>> %type <uintVal> snap_shot
>>> snap_shot
>>> : SNAPSHOT
>>> | SNAPSHOT TABLE
>>> | SNAPSHOT TABLE STABILITY
>>> + | SNAPSHOT SHARING FROM <N>
>> SNAPSHOT BASED ON <N>
>> ?
>>
> Do you think with this words it's clear that the new transaction uses
> the same snapshot used in <N>, instead of incorrectly saying that it
> will use <N> as the snapshot for the new transaction?
>
> Thinking in these terms, I'm more inclined to adapt (renaming SHARING to
> SHARED) Vlad's syntax to:
>
> SET TRANSACTION ISOLATION LEVEL SNAPSHOT SHARED FROM <N>

   For me both variants are OK :) Probably native english speakers could
offer something better and less ambiguous.

   Also, i offer to add additional rule for transaction which should export
its snapshot data (it allows to avoid export by all transactions), something
like:

   SET TRANSACTION ISOLATION LEVEL SNAPSHOT WITH SHARED SNAPSHOT

Not sure i like it :)

Regards,
Vlad

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Start transaction from base transaction

Adriano dos Santos Fernandes-3
Em 05/05/2017 18:01, Vlad Khorsun escreveu:

>
>    Also, i offer to add additional rule for transaction which should export
> its snapshot data (it allows to avoid export by all transactions), something
> like:
>
>    SET TRANSACTION ISOLATION LEVEL SNAPSHOT WITH SHARED SNAPSHOT
>

As we talk about active transactions, why did you want to "export"
snapshot explicitly instead of share the data already available like I
did (badly implemented yet, but possible) when requested by who want it?


Adriano

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Start transaction from base transaction

Vlad Khorsun-2
06.05.2017 0:17, Adriano dos Santos Fernandes wrote:

> Em 05/05/2017 18:01, Vlad Khorsun escreveu:
>
>>
>>     Also, i offer to add additional rule for transaction which should export
>> its snapshot data (it allows to avoid export by all transactions), something
>> like:
>>
>>     SET TRANSACTION ISOLATION LEVEL SNAPSHOT WITH SHARED SNAPSHOT
>>
>
> As we talk about active transactions, why did you want to "export"
> snapshot explicitly instead of share the data already available like I
> did (badly implemented yet, but possible) when requested by who want it?

   To avoid work and resources overhead when it is not required. Agree, snapshot
of a far not every transaction will be ever used by another transaction.

Regards,
Vlad

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Start transaction from base transaction

liviuslivius@poczta.onet.pl
In reply to this post by Vlad Khorsun-2
Hi,

for me name is confusing - beacause here can be two cases:
1. Snapshot transaction is shared
2. only view of database from its start point is shared and any modification
caused by base snapshot and any sharing transaction is not shared between
transactions.
Name must specify real maining.

And question araise - is it possible that shared transaction with share from
base transaction also possible to be shared? (i do not know if you
understand me)

regards,
Karol Bieniaszewski


-----Oryginalna wiadomość-----
From: Vlad Khorsun
Sent: Friday, May 5, 2017 11:01 PM
To: [hidden email]
Subject: Re: [Firebird-devel] Start transaction from base transaction

05.05.2017 21:10, Adriano dos Santos Fernandes wrote:

> On 05/05/2017 14:43, Dmitry Yemanov wrote:
>> 05.05.2017 20:01, Vlad Khorsun wrote:
>>> %type <uintVal> snap_shot
>>> snap_shot
>>> : SNAPSHOT
>>> | SNAPSHOT TABLE
>>> | SNAPSHOT TABLE STABILITY
>>> + | SNAPSHOT SHARING FROM <N>
>> SNAPSHOT BASED ON <N>
>> ?
>>
> Do you think with this words it's clear that the new transaction uses
> the same snapshot used in <N>, instead of incorrectly saying that it
> will use <N> as the snapshot for the new transaction?
>
> Thinking in these terms, I'm more inclined to adapt (renaming SHARING to
> SHARED) Vlad's syntax to:
>
> SET TRANSACTION ISOLATION LEVEL SNAPSHOT SHARED FROM <N>

   For me both variants are OK :) Probably native english speakers could
offer something better and less ambiguous.

   Also, i offer to add additional rule for transaction which should export
its snapshot data (it allows to avoid export by all transactions), something
like:

   SET TRANSACTION ISOLATION LEVEL SNAPSHOT WITH SHARED SNAPSHOT

Not sure i like it :)

Regards,
Vlad

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel 


---
Ta wiadomość została sprawdzona na obecność wirusów przez oprogramowanie antywirusowe Avast.
https://www.avast.com/antivirus


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Start transaction from base transaction

Vlad Khorsun-2
06.05.2017 11:47, livius wrote:
> Hi,
>
> for me name is confusing - beacause here can be two cases:
> 1. Snapshot transaction is shared

   Looks like wrong\incomplete definition, as

> 2. only view of database from its start point is shared and any modification
> caused by base snapshot and any sharing transaction is not shared between
> transactions.

we speak about this one.

> Name must specify real maining.

   Yes, but we should avoid to write whole novels at SQL statements ;)

> And question araise - is it possible that shared transaction with share from
> base transaction also possible to be shared? (i do not know if you
> understand me)

   It have no sence (if i understand you :) )

Regards,
Vlad

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Start transaction from base transaction

liviuslivius@poczta.onet.pl

>Yes, but we should avoid to write whole novels at SQL statements ;)

Agree - but to fast chice is also not good

> It have no sence (if i understand you :) )
Maybe, but it should be prohibited in code or designed to do not create
wrong behavior
You know if something is possible someone use it
and i mean:
base transaction
transaction 2 share base transaction
transaction 3 share base transaction
and someone try
transaction 4 share e.g. transaction 2 ;-) in this point it should share
base or do not alow it
but maybe heare are not any problem?

regards,
Karol Bieniaszewski

-----Oryginalna wiadomość-----
From: Vlad Khorsun
Sent: Saturday, May 6, 2017 11:55 AM
To: [hidden email]
Subject: Re: [Firebird-devel] Start transaction from base transaction

06.05.2017 11:47, livius wrote:
> Hi,
>
> for me name is confusing - beacause here can be two cases:
> 1. Snapshot transaction is shared

   Looks like wrong\incomplete definition, as

> 2. only view of database from its start point is shared and any
> modification
> caused by base snapshot and any sharing transaction is not shared between
> transactions.

we speak about this one.

> Name must specify real maining.

   Yes, but we should avoid to write whole novels at SQL statements ;)

> And question araise - is it possible that shared transaction with share
> from
> base transaction also possible to be shared? (i do not know if you
> understand me)

   It have no sence (if i understand you :) )

Regards,
Vlad

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel 


---
Ta wiadomość została sprawdzona na obecność wirusów przez oprogramowanie antywirusowe Avast.
https://www.avast.com/antivirus


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Start transaction from base transaction

Adriano dos Santos Fernandes-3
Em 06/05/2017 09:15, livius escreveu:

>
>> Yes, but we should avoid to write whole novels at SQL statements ;)
>
> Agree - but to fast chice is also not good
>
>> It have no sence (if i understand you :) )
> Maybe, but it should be prohibited in code or designed to do not create
> wrong behavior
> You know if something is possible someone use it
> and i mean:
> base transaction
> transaction 2 share base transaction
> transaction 3 share base transaction
> and someone try
> transaction 4 share e.g. transaction 2 ;-) in this point it should share
> base or do not alow it
> but maybe heare are not any problem?
>

transaction 4 will start with the same snapshot started in transaction,
transaction 2 and transaction 3.


Adriano

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[SPAM] Re: Start transaction from base transaction

Vlad Khorsun-2
In reply to this post by liviuslivius@poczta.onet.pl
06.05.2017 15:15, livius wrote:
>
>> Yes, but we should avoid to write whole novels at SQL statements ;)
>
> Agree - but to fast chice is also not good

   Could you offer better syntax ?

>> It have no sence (if i understand you :) )
> Maybe, but it should be prohibited in code or designed to do not create
> wrong behavior

   I prefer second when possible. And this is one more reason for explicitly
export transaction snapshot.

> You know if something is possible someone use it
> and i mean:
> base transaction
> transaction 2 share base transaction
> transaction 3 share base transaction
> and someone try
> transaction 4 share e.g. transaction 2 ;-) in this point it should share
> base or do not alow it
> but maybe heare are not any problem?

   So far, I see no problem (except of strange coding\design of such user application).

   Also, we could disable to export and import snapshots at the same time and
it will make such cases impossible. I offer to go this way.

Regards,
Vlad

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
12345
Loading...