FWD » Core Development » Database

05/09/2022

06:33 AM Bug #3896: improve performance of the _lock metadata implementation

Igor Skornyakov wrote:
> Constantin Asofiei wrote:
> > Igor, please test what happens if you try to lock a meta @_u... Constantin Asofiei

06:10 AM Bug #3896: improve performance of the _lock metadata implementation

Constantin Asofiei wrote:
> Igor, please test what happens if you try to lock a meta @_user@ record or do an explici... Igor Skornyakov

05:26 AM Bug #3896: improve performance of the _lock metadata implementation

Constantin Asofiei wrote:
> What I meant is for @LockTableUpdater.lockChanged@ to do nothing and log a WARNING if th... Igor Skornyakov

05:22 AM Bug #3896: improve performance of the _lock metadata implementation

Igor Skornyakov wrote:
> Constantin Asofiei wrote:
> > Igor Skornyakov wrote:
> > > If I understand correctly @Loc... Constantin Asofiei

04:59 AM Bug #3896: improve performance of the _lock metadata implementation

Constantin Asofiei wrote:
> Igor Skornyakov wrote:
> > If I understand correctly @LockTableUpdater@ is not created ... Igor Skornyakov

04:42 AM Bug #3896: improve performance of the _lock metadata implementation

Igor Skornyakov wrote:
> If I understand correctly @LockTableUpdater@ is not created for the meta database, so I sug... Constantin Asofiei

04:37 AM Bug #3896: improve performance of the _lock metadata implementation

Constantin Asofiei wrote:
> Igor Skornyakov wrote:
> > Indeed, the problem is that @meta_user@ is not included neit... Igor Skornyakov

04:23 AM Bug #3896: improve performance of the _lock metadata implementation

Igor Skornyakov wrote:
> Indeed, the problem is that @meta_user@ is not included neither to @FILE_NUM@ nor to @FILE_... Constantin Asofiei

04:16 AM Bug #3896: improve performance of the _lock metadata implementation

Indeed, the problem is that @meta_user@ is not included neither to @FILE_NUM@ nor to @FILE_NUM_BY_TBL_NAME@ maps in t... Igor Skornyakov

03:01 AM Bug #3896: improve performance of the _lock metadata implementation

Constantin Asofiei wrote:
> In a standalone test use a @create _user.@ and a @find first _user exclusive-lock@.
O... Igor Skornyakov

02:59 AM Bug #3896: improve performance of the _lock metadata implementation

In a standalone test use a @create _user.@ and a @find first _user exclusive-lock@. Constantin Asofiei

02:41 AM Bug #3896: improve performance of the _lock metadata implementation

Constantin Asofiei wrote:
> Igor, most likely the abend is from the LockTableUpdater changes - please take a look, t... Igor Skornyakov

02:29 AM Bug #3896: improve performance of the _lock metadata implementation

Igor, most likely the abend is from the LockTableUpdater changes - please take a look, this abend is seen in a custom... Constantin Asofiei

02:26 AM Bug #3896: improve performance of the _lock metadata implementation

Constantin Asofiei wrote:
> Igor, please test what happens if you try to lock a meta @_user@ record or do an explici... Igor Skornyakov

02:12 AM Bug #3896: improve performance of the _lock metadata implementation

Igor, please test what happens if you try to lock a meta @_user@ record or do an explicit CREATE on the @_user@ table... Constantin Asofiei

05/03/2022

09:23 AM Bug #6310: for first "first()", exclusive-lock, raises FWD exception while 4GL raises at the fiel...

Greg Shah wrote:
> Please create a bug in the Database project for this issue. We will focus on item 1 and then see... Tijs Wickardt

08:56 AM Bug #6310: for first "first()", exclusive-lock, raises FWD exception while 4GL raises at the fiel...

Greg Shah wrote:
> In regard to the unrelated issues, make a list and post them here. We will move them to another ... Tijs Wickardt

08:55 AM Bug #6310 (New): for first "first()", exclusive-lock, raises FWD exception while 4GL raises at th...

Tijs Wickardt

05/02/2022

09:32 AM Bug #3896 (Closed): improve performance of the _lock metadata implementation

Eric Faulhaber

08:05 AM Bug #3896: improve performance of the _lock metadata implementation

Greg Shah wrote:
> Is this complete?
I think so. Igor Skornyakov

08:04 AM Bug #3896: improve performance of the _lock metadata implementation

Is this complete? Greg Shah

04/28/2022

11:40 AM Feature #1587: implement full support for word indexes

I encountered in a customer's data dump the following situation:
The @.df@ file looks like this:... Ovidiu Maxiniuc

04/27/2022

01:29 PM Bug #6301: incorrect initialization of date-related fields with today and now literals

The issue can be observed at runtime: the "now" moment is not evaluated for each record at the moment the record is c... Ovidiu Maxiniuc

01:18 PM Bug #6301 (Test): incorrect initialization of date-related fields with today and now literals

Ovidiu Maxiniuc

07:42 AM Bug #3896: improve performance of the _lock metadata implementation

Eric Faulhaber wrote:
> As noted earlier, I don't want to address this unless we find it's needed. Let's go with the... Igor Skornyakov

07:34 AM Bug #3896: improve performance of the _lock metadata implementation

Greg Shah wrote:
> The moment that the @_lock@ table is ever accessed by converted 4GL code, maintenance starts. At... Igor Skornyakov

07:32 AM Bug #3896: improve performance of the _lock metadata implementation

Igor Skornyakov wrote:
> Actually, what Eric suggests (the batch VST cleanup) can reduce the duration of the maint... Eric Faulhaber

07:28 AM Bug #3896: improve performance of the _lock metadata implementation

The moment that the @_lock@ table is ever accessed by converted 4GL code, maintenance starts. At that point, the @_l... Greg Shah

07:22 AM Bug #3896: improve performance of the _lock metadata implementation

Greg Shah wrote:
> > The actual maintenance starts when the first lock persisted because of the access is released.
... Igor Skornyakov

07:16 AM Bug #3896: improve performance of the _lock metadata implementation

> The actual maintenance starts when the first lock persisted because of the access is released.
By "access is rel... Greg Shah

06:59 AM Bug #3896: improve performance of the _lock metadata implementation

Greg Shah wrote:
> The moment any access to the @_lock@ table occurs, we start expending CPU cycles maintaining that... Igor Skornyakov

06:55 AM Bug #3896: improve performance of the _lock metadata implementation

The moment any access to the @_lock@ table occurs, we start expending CPU cycles maintaining that table. Do I unders... Greg Shah

06:47 AM Bug #3896: improve performance of the _lock metadata implementation

Greg Shah wrote:
> > Moreover, we submit a clean task only if we see that the lock data was persisted.
>
> What d... Igor Skornyakov

06:39 AM Bug #3896: improve performance of the _lock metadata implementation

> Moreover, we submit a clean task only if we see that the lock data was persisted.
What do you mean by "persisted... Greg Shah

06:27 AM Bug #3896: improve performance of the _lock metadata implementation

Greg Shah wrote:
> > After all, if we expect that user access to the _Lock table will be rare, then the cost of the ... Igor Skornyakov

06:19 AM Bug #3896: improve performance of the _lock metadata implementation

> After all, if we expect that user access to the _Lock table will be rare, then the cost of the background maintenan... Greg Shah

06:11 AM Bug #3896: improve performance of the _lock metadata implementation

Greg Shah wrote:
> Eric controls this decision.
>
> I am not suggesting leaving the code as you have written it. ... Igor Skornyakov

05:54 AM Bug #3896: improve performance of the _lock metadata implementation

Eric controls this decision.
I am not suggesting leaving the code as you have written it. I am suggesting that th... Greg Shah

05:47 AM Bug #3896: improve performance of the _lock metadata implementation

Greg Shah wrote:
> Are we *really, really sure* that this incremental maintenance approach is needed? The @_lock@ d... Igor Skornyakov

05:36 AM Bug #3896: improve performance of the _lock metadata implementation

Are we *really, really sure* that this incremental maintenance approach is needed? The @_lock@ data is expected to b... Greg Shah

02:27 AM Bug #3896: improve performance of the _lock metadata implementation

Eric Faulhaber wrote:
> Nevertheless, the above scenario could happen (who knows how developers have instrumented so... Igor Skornyakov

02:17 AM Bug #3896: improve performance of the _lock metadata implementation

Eric Faulhaber wrote:
> Well, the block nesting of the test seems a little odd to me, but it should work. You must... Igor Skornyakov

11:00 PM Bug #3896: improve performance of the _lock metadata implementation

Igor Skornyakov wrote:
> Eric Faulhaber wrote:
> > Why are we hitting the VST on a state change event? Presumably, ... Eric Faulhaber

10:20 PM Bug #3896: improve performance of the _lock metadata implementation

Igor Skornyakov wrote:
> I see some strange results with a simple 4GL test.
> Consider the following program:
> [.... Eric Faulhaber

04/26/2022

06:24 AM Bug #3896: improve performance of the _lock metadata implementation

I see some strange results with a simple 4GL test.
Consider the following program:... Igor Skornyakov

04/25/2022

04:33 PM Bug #3896: improve performance of the _lock metadata implementation

Eric Faulhaber wrote:
> Code review @_lock3.diff@ (applied to 3821c/13813):
>
> 1) I didn't notice this when I re... Igor Skornyakov

03:21 PM Bug #3896: improve performance of the _lock metadata implementation

Code review @_lock3.diff@ (applied to 3821c/13813):
1) I didn't notice this when I reviewed an earlier version of ... Eric Faulhaber

04/19/2022

12:16 PM Bug #6275: SKIP-DELETED-RECORD implementation

Greg Shah wrote:
> Ovidiu: Please review.
A single question: calls to @stopOnSkippedRecord@ occur on @first@, @ne... Ovidiu Maxiniuc

04/13/2022

07:06 AM Bug #6275: SKIP-DELETED-RECORD implementation

Ovidiu: Please review. Greg Shah

04:16 AM Bug #6275: SKIP-DELETED-RECORD implementation

@SKIP-DELETED-RECORD@ was implemented as a part of #5882. In turned out that these changes weren't necessary for fixi... Stanislav Lomany

04:02 AM Bug #6275 (Review): SKIP-DELETED-RECORD implementation

Stanislav Lomany

04:16 AM Bug #3896: improve performance of the _lock metadata implementation

Reworked based on the code review and tested with a large customer app.
Please review the final version (attached). Igor Skornyakov

04/12/2022

06:21 PM Feature #4722 (WIP): data import should be able to run with only the converted application jar fi...

Partial work in this area was done in recent commits (revisions: 13695, 13746, 13753, 13776 of branch 3821c). Ovidiu Maxiniuc

04/11/2022

02:08 PM Bug #3896: improve performance of the _lock metadata implementation

Eric Faulhaber wrote:
> Igor Skornyakov wrote:
>
> > The problem with combining multiple updates into a single tr... Igor Skornyakov

02:03 PM Bug #3896: improve performance of the _lock metadata implementation

Igor Skornyakov wrote:
> The problem with combining multiple updates into a single transaction is that we need to ... Eric Faulhaber

01:51 PM Bug #3896: improve performance of the _lock metadata implementation

Eric Faulhaber wrote:
> Igor Skornyakov wrote:
>
> > [...]
> > Anyway, I will think how to improve the current l... Igor Skornyakov

01:01 PM Bug #3896 (Review): improve performance of the _lock metadata implementation

Eric Faulhaber

12:56 PM Bug #3896: improve performance of the _lock metadata implementation

Eric Faulhaber wrote:
> Igor Skornyakov wrote:
>
> > [...]
> > Anyway, I will think how to improve the current l... Igor Skornyakov

12:52 PM Bug #3896: improve performance of the _lock metadata implementation

Igor Skornyakov wrote:
> [...]
> Anyway, I will think how to improve the current logic.
As I noted, it is ok t... Eric Faulhaber

12:49 PM Bug #3896: improve performance of the _lock metadata implementation

Eric Faulhaber wrote:
> @_lock2.diff@ patch code review:
>
> Typo at @FwdJMX@:173: @faild@ -> @failed@.
>
> @L... Igor Skornyakov

12:19 PM Bug #3896: improve performance of the _lock metadata implementation

@_lock2.diff@ patch code review:
Typo at @FwdJMX@:173: @faild@ -> @failed@.
@LockTableUpdater@:
Please remov... Eric Faulhaber