Open SCanzano-ready opened 7 months ago
Good point! Maybe we need a flag to turn transaction off/on
On Wed, Feb 7, 2024 at 6:29 PM SCanzano-ready @.***> wrote:
The great thing about using the install command is that all of it appears to be wrapped around a TSTART, so if an error occurs it's TROLLBACK'ed.
However, the delivery of the module includes compiling the classes and associated routines for a class. All of this introduces database locks via Lock +. For really large modules this can cause an issue if locksiz is not adequately large. When this occurs ZPM reports an error about not being able to acquire a lock. It's not that something else has a lock, but rather the lock table has exhausted the locksiz.
It seems like this might be better managed if ##class(%SYSTEM.OBJ).Load or
class(%SYSTEM.OBJ).Compile manage the transaction and specifically better
manage the number of locks being added.
I also note that because of the lock table filling up when this occurs, before the trollback is done, I cannot access the system management portal.
— Reply to this email directly, view it on GitHub https://github.com/intersystems/ipm/issues/442, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAVHEP3Q7OXWVG6RUQBRRLDYSPB2HAVCNFSM6AAAAABC6KGFT6VHI2DSMVQWIX3LMV43ASLTON2WKOZSGEZDGNRTGIYDAMY . You are receiving this because you are subscribed to this thread.Message ID: @.***>
I like the fact that the transaction is enabled, this prevents a module from being partially installed. If we install module version 1.0.1 and then try and install 1.0.2 I wouldn't want part of 1.0.2 to be installed. 1.0.2 either has to be fully successful or not.
On Wed, Feb 7, 2024 at 1:34 PM Evgeny Shvarov @.***> wrote:
Good point! Maybe we need a flag to turn transaction off/on
On Wed, Feb 7, 2024 at 6:29 PM SCanzano-ready @.***> wrote:
The great thing about using the install command is that all of it appears to be wrapped around a TSTART, so if an error occurs it's TROLLBACK'ed.
However, the delivery of the module includes compiling the classes and associated routines for a class. All of this introduces database locks via Lock +. For really large modules this can cause an issue if locksiz is not adequately large. When this occurs ZPM reports an error about not being able to acquire a lock. It's not that something else has a lock, but rather the lock table has exhausted the locksiz.
It seems like this might be better managed if ##class(%SYSTEM.OBJ).Load or
class(%SYSTEM.OBJ).Compile manage the transaction and specifically
better manage the number of locks being added.
I also note that because of the lock table filling up when this occurs, before the trollback is done, I cannot access the system management portal.
— Reply to this email directly, view it on GitHub https://github.com/intersystems/ipm/issues/442, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AAVHEP3Q7OXWVG6RUQBRRLDYSPB2HAVCNFSM6AAAAABC6KGFT6VHI2DSMVQWIX3LMV43ASLTON2WKOZSGEZDGNRTGIYDAMY>
. You are receiving this because you are subscribed to this thread.Message ID: @.***>
— Reply to this email directly, view it on GitHub https://github.com/intersystems/ipm/issues/442#issuecomment-1932643854, or unsubscribe https://github.com/notifications/unsubscribe-auth/A5DDTQ4E66B6K7ABKQ7GAH3YSPCM5AVCNFSM6AAAAABC6KGFT6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZSGY2DGOBVGQ . You are receiving this because you authored the thread.Message ID: @.***>
--
Stephen Canzano
Principal Software Architect
[image: twitter-icon-square-logo-108D17D373-seeklogo.com] https://hubs.ly/Q01lkwTs0 [image: download] https://hubs.ly/Q01lkwSF0 [image: email icon ready linkedin-1] https://hubs.ly/Q01lkwZ60
Mobile: +1 (239)214-0170
Office: +1 (212) 877-3307 + 5087
@.***
www.readycomputing.com https://hubs.ly/Q01lkwCS0
150 Beekman Street, Floor 3, New York, NY 10038
-- This is not a secure transmission. The information contained in this transmission is highly prohibited from containing highly-confidential data/information protected by federal and state privacy laws. It is intended only for the use of the person(s) named above. If you are not the intended recipient, please contact the sender by email and destroy all copies of the original message. All electronic communications to or from the Company are the property of the Company and subject to monitoring.
If you watch the lock table during an install you'll see that we have a tremendous number of locks added.
On Wed, Feb 7, 2024 at 1:38 PM Stephen Canzano < @.***> wrote:
I like the fact that the transaction is enabled, this prevents a module from being partially installed. If we install module version 1.0.1 and then try and install 1.0.2 I wouldn't want part of 1.0.2 to be installed. 1.0.2 either has to be fully successful or not.
On Wed, Feb 7, 2024 at 1:34 PM Evgeny Shvarov @.***> wrote:
Good point! Maybe we need a flag to turn transaction off/on
On Wed, Feb 7, 2024 at 6:29 PM SCanzano-ready @.***> wrote:
The great thing about using the install command is that all of it appears to be wrapped around a TSTART, so if an error occurs it's TROLLBACK'ed.
However, the delivery of the module includes compiling the classes and associated routines for a class. All of this introduces database locks via Lock +. For really large modules this can cause an issue if locksiz is not adequately large. When this occurs ZPM reports an error about not being able to acquire a lock. It's not that something else has a lock, but rather the lock table has exhausted the locksiz.
It seems like this might be better managed if ##class(%SYSTEM.OBJ).Load or
class(%SYSTEM.OBJ).Compile manage the transaction and specifically
better manage the number of locks being added.
I also note that because of the lock table filling up when this occurs, before the trollback is done, I cannot access the system management portal.
— Reply to this email directly, view it on GitHub https://github.com/intersystems/ipm/issues/442, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AAVHEP3Q7OXWVG6RUQBRRLDYSPB2HAVCNFSM6AAAAABC6KGFT6VHI2DSMVQWIX3LMV43ASLTON2WKOZSGEZDGNRTGIYDAMY>
. You are receiving this because you are subscribed to this thread.Message ID: @.***>
— Reply to this email directly, view it on GitHub https://github.com/intersystems/ipm/issues/442#issuecomment-1932643854, or unsubscribe https://github.com/notifications/unsubscribe-auth/A5DDTQ4E66B6K7ABKQ7GAH3YSPCM5AVCNFSM6AAAAABC6KGFT6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZSGY2DGOBVGQ . You are receiving this because you authored the thread.Message ID: @.***>
--
Stephen Canzano
Principal Software Architect
[image: twitter-icon-square-logo-108D17D373-seeklogo.com] https://hubs.ly/Q01lkwTs0 [image: download] https://hubs.ly/Q01lkwSF0 [image: email icon ready linkedin-1] https://hubs.ly/Q01lkwZ60
Mobile: +1 (239)214-0170
Office: +1 (212) 877-3307 + 5087
@.***
www.readycomputing.com https://hubs.ly/Q01lkwCS0
150 Beekman Street, Floor 3, New York, NY 10038
--
Stephen Canzano
Principal Software Architect
[image: twitter-icon-square-logo-108D17D373-seeklogo.com] https://hubs.ly/Q01lkwTs0 [image: download] https://hubs.ly/Q01lkwSF0 [image: email icon ready linkedin-1] https://hubs.ly/Q01lkwZ60
Mobile: +1 (239)214-0170
Office: +1 (212) 877-3307 + 5087
@.***
www.readycomputing.com https://hubs.ly/Q01lkwCS0
150 Beekman Street, Floor 3, New York, NY 10038
-- This is not a secure transmission. The information contained in this transmission is highly prohibited from containing highly-confidential data/information protected by federal and state privacy laws. It is intended only for the use of the person(s) named above. If you are not the intended recipient, please contact the sender by email and destroy all copies of the original message. All electronic communications to or from the Company are the property of the Company and subject to monitoring.
I quickly had over 1000 locks.
I also note that I seem to have 2 locks for each persistent class. ^oddDEF("RC.EnsLib.Schema.Data.ADD")
^oddEXTR("RC.EnsLib.Schema.Data.ADD","NoT") since locks are done by agreement I wonder if the %AcquireLock and %ReleaseLock in the %Dictionary classes could be made smarter to just always check ^oddDEF and not add a second entry in the lock table for ^oddEXTR.
On Wed, Feb 7, 2024 at 1:40 PM Stephen Canzano < @.***> wrote:
If you watch the lock table during an install you'll see that we have a tremendous number of locks added.
On Wed, Feb 7, 2024 at 1:38 PM Stephen Canzano < @.***> wrote:
I like the fact that the transaction is enabled, this prevents a module from being partially installed. If we install module version 1.0.1 and then try and install 1.0.2 I wouldn't want part of 1.0.2 to be installed. 1.0.2 either has to be fully successful or not.
On Wed, Feb 7, 2024 at 1:34 PM Evgeny Shvarov @.***> wrote:
Good point! Maybe we need a flag to turn transaction off/on
On Wed, Feb 7, 2024 at 6:29 PM SCanzano-ready @.***> wrote:
The great thing about using the install command is that all of it appears to be wrapped around a TSTART, so if an error occurs it's TROLLBACK'ed.
However, the delivery of the module includes compiling the classes and associated routines for a class. All of this introduces database locks via Lock +. For really large modules this can cause an issue if locksiz is not adequately large. When this occurs ZPM reports an error about not being able to acquire a lock. It's not that something else has a lock, but rather the lock table has exhausted the locksiz.
It seems like this might be better managed if
class(%SYSTEM.OBJ).Load or
class(%SYSTEM.OBJ).Compile manage the transaction and specifically
better manage the number of locks being added.
I also note that because of the lock table filling up when this occurs, before the trollback is done, I cannot access the system management portal.
— Reply to this email directly, view it on GitHub https://github.com/intersystems/ipm/issues/442, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AAVHEP3Q7OXWVG6RUQBRRLDYSPB2HAVCNFSM6AAAAABC6KGFT6VHI2DSMVQWIX3LMV43ASLTON2WKOZSGEZDGNRTGIYDAMY>
. You are receiving this because you are subscribed to this thread.Message ID: @.***>
— Reply to this email directly, view it on GitHub https://github.com/intersystems/ipm/issues/442#issuecomment-1932643854, or unsubscribe https://github.com/notifications/unsubscribe-auth/A5DDTQ4E66B6K7ABKQ7GAH3YSPCM5AVCNFSM6AAAAABC6KGFT6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZSGY2DGOBVGQ . You are receiving this because you authored the thread.Message ID: @.***>
--
Stephen Canzano
Principal Software Architect
[image: twitter-icon-square-logo-108D17D373-seeklogo.com] https://hubs.ly/Q01lkwTs0 [image: download] https://hubs.ly/Q01lkwSF0 [image: email icon ready linkedin-1] https://hubs.ly/Q01lkwZ60
Mobile: +1 (239)214-0170
Office: +1 (212) 877-3307 + 5087
@.***
www.readycomputing.com https://hubs.ly/Q01lkwCS0
150 Beekman Street, Floor 3, New York, NY 10038
--
Stephen Canzano
Principal Software Architect
[image: twitter-icon-square-logo-108D17D373-seeklogo.com] https://hubs.ly/Q01lkwTs0 [image: download] https://hubs.ly/Q01lkwSF0 [image: email icon ready linkedin-1] https://hubs.ly/Q01lkwZ60
Mobile: +1 (239)214-0170
Office: +1 (212) 877-3307 + 5087
@.***
www.readycomputing.com https://hubs.ly/Q01lkwCS0
150 Beekman Street, Floor 3, New York, NY 10038
--
Stephen Canzano
Principal Software Architect
[image: twitter-icon-square-logo-108D17D373-seeklogo.com] https://hubs.ly/Q01lkwTs0 [image: download] https://hubs.ly/Q01lkwSF0 [image: email icon ready linkedin-1] https://hubs.ly/Q01lkwZ60
Mobile: +1 (239)214-0170
Office: +1 (212) 877-3307 + 5087
@.***
www.readycomputing.com https://hubs.ly/Q01lkwCS0
150 Beekman Street, Floor 3, New York, NY 10038
-- This is not a secure transmission. The information contained in this transmission is highly prohibited from containing highly-confidential data/information protected by federal and state privacy laws. It is intended only for the use of the person(s) named above. If you are not the intended recipient, please contact the sender by email and destroy all copies of the original message. All electronic communications to or from the Company are the property of the Company and subject to monitoring.
We already have a flag to turn transactions off - in zpm install and load you can add:
-DNoTransaction=1
You can also set this up as a default behavior - see output of:
zpm "help default-modifiers"
We need better docs around this for sure!
but I want transactions, I just dont want to exhaust the lock table.
On Wed, Feb 7, 2024 at 1:52 PM Tim Leavitt @.***> wrote:
We already have a flag to turn transactions off - in zpm install and load you can add:
-DNoTransaction=1
You can also set this up as a default behavior - see output of:
zpm "help default-modifiers"
We need better docs around this for sure!
— Reply to this email directly, view it on GitHub https://github.com/intersystems/ipm/issues/442#issuecomment-1932670926, or unsubscribe https://github.com/notifications/unsubscribe-auth/A5DDTQ4SJ5AH7DSH3OG3LVLYSPEPTAVCNFSM6AAAAABC6KGFT6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZSGY3TAOJSGY . You are receiving this because you authored the thread.Message ID: @.***>
--
Stephen Canzano
Principal Software Architect
[image: twitter-icon-square-logo-108D17D373-seeklogo.com] https://hubs.ly/Q01lkwTs0 [image: download] https://hubs.ly/Q01lkwSF0 [image: email icon ready linkedin-1] https://hubs.ly/Q01lkwZ60
Mobile: +1 (239)214-0170
Office: +1 (212) 877-3307 + 5087
@.***
www.readycomputing.com https://hubs.ly/Q01lkwCS0
150 Beekman Street, Floor 3, New York, NY 10038
-- This is not a secure transmission. The information contained in this transmission is highly prohibited from containing highly-confidential data/information protected by federal and state privacy laws. It is intended only for the use of the person(s) named above. If you are not the intended recipient, please contact the sender by email and destroy all copies of the original message. All electronic communications to or from the Company are the property of the Company and subject to monitoring.
Good point, I read too quickly. More investigation is needed, just throwing some ideas:
The quick operational solution would be to increase locksiz (and perhaps gmheap).
Short of that, we could also look into lock escalation options at the IPM level - for regular persistent classes this happens automatically based on the lock escalation threshold; maybe we don't do that in %Dictionary and such? The problem is that this interacts poorly with another IPM feature, being able to load dependencies in parallel.
There have been points in the past where IPM has had to manage all the locking itself because of the way it ends up calling the various $System.OBJ entry points. I don't recall the current status in that regard.
The great thing about using the install command is that all of it appears to be wrapped around a TSTART, so if an error occurs it's TROLLBACK'ed.
However, the delivery of the module includes compiling the classes and associated routines for a class. All of this introduces database locks via Lock +. For really large modules this can cause an issue if locksiz is not adequately large. When this occurs ZPM reports an error about not being able to acquire a lock. It's not that something else has a lock, but rather the lock table has exhausted the locksiz.
It seems like this might be better managed if ##class(%SYSTEM.OBJ).Load or ##class(%SYSTEM.OBJ).Compile manage the transaction and specifically better manage the number of locks being added.
I also note that because of the lock table filling up when this occurs, before the trollback is done, I cannot access the system management portal.