Asked to Not Use Transactions and to Use A Workaround to Simulate One

I’ve been developing T-SQL for several years and am always digging in further, continuing to learn all I can about all aspects of the language. I recently started working at a new company and have received what I think is an odd suggestion regarding transactions. Don’t ever use them. Instead, use a workaround that simulates a transaction. This is coming from our DBA who works in one database with a lot of transactions and subsequently, a lot of blocking. The database I primarily work in does not suffer from this issue and I see transactions have been used in the past.

I understand that blocking is expected with transactions as it’s in their nature to do so and if you can get away without using one, by all means do it. But I have many occasions where each statement MUST execute successfully. If one fails they all must fail to commit.

I’ve always kept the scope of my transactions as narrow as possible, always used in conjunction with SET XACT_ABORT ON and always within a TRY/CATCH.

Example:

CREATE SCHEMA someschema; GO   CREATE TABLE someschema.tableA (id   INT NOT NULL IDENTITY(1, 1) PRIMARY KEY,   ColA VARCHAR(10) NOT NULL ); GO  CREATE TABLE someschema.tableB (id   INT NOT NULL IDENTITY(1, 1) PRIMARY KEY,   ColB VARCHAR(10) NOT NULL );  GO   CREATE PROCEDURE someschema.ProcedureName @ColA VARCHAR(10),                                            @ColB VARCHAR(10) AS SET NOCOUNT, XACT_ABORT ON; BEGIN BEGIN TRY     BEGIN TRANSACTION;      INSERT INTO someschema.tableA(ColA)     VALUES(@ColA);      INSERT INTO someschema.tableB(ColB)     VALUES(@ColB);  --Implement error     SELECT 1/0       COMMIT TRANSACTION; END TRY BEGIN CATCH     IF @@trancount > 0     BEGIN         ROLLBACK TRANSACTION;     END;     THROW;     RETURN; END CATCH; END; GO  

Here is what they suggested that I do.

GO    CREATE PROCEDURE someschema.ProcedureNameNoTransaction @ColA VARCHAR(10),                                                         @ColB VARCHAR(10) AS SET NOCOUNT ON; BEGIN BEGIN TRY     DECLARE @tableAid INT;     DECLARE @tableBid INT;      INSERT INTO someschema.tableA(ColA)     VALUES(@ColA);     SET @tableAid = SCOPE_IDENTITY();      INSERT INTO someschema.tableB(ColB)     VALUES(@ColB);     SET @tableBid = SCOPE_IDENTITY();  --Implement error     SELECT 1/0   END TRY BEGIN CATCH     DELETE FROM someschema.tableA     WHERE id = @tableAid;      DELETE FROM someschema.tableB     WHERE id = @tableBid;      THROW;      RETURN; END CATCH; END; GO 

My question to the community is as follows. Does this make sense as a viable workaround for transactions?

My opinion from what I know about transactions and what the solution is proposing is that no, this isn’t a viable solution and introduces many points of failure.

In the suggested workaround, I see four implicit transactions occurring. The two inserts in the try and then two more transactions for the deletes in the catch. It does “undo” the inserts but without rolling back anything so nothing is actually rolled back.

This is a very basic example to demonstrate the concept they are suggesting. Some of the actual stored procedures I have been doing this in make them exhaustively long and difficult to manage because “rolling back” multiple result sets vs two parameter values in this example becomes quite complicated as you could imagine. Since “rolling back” is being done manually now, the opportunity to miss something because real.

Another issue that I think exists is for timeouts or severed connections. Does this still get rolled back? This is my understanding of why SET XACT_ABORT ON should be used so that in these cases, the transaction will roll back.

Thanks for your feedback in advance!

Workaround for DSolve in V 12 when it gives undefined as solution to 1D heat PDE?

Comparing the following, all done from clean kernel


Mathematica graphics


Mathematica graphics

The strange thing is that V 12 can solve this same PDE without the assumptions

k    = 1/10; A = 60; pde  = D[u[x, t], t] == k*D[u[x, t], {x, 2}]; bc   = u[0, t] == A; ic   = u[x, 0] == 0; sol  = DSolve[{pde, bc, ic}, u[x, t], {x, t}] 

Mathematica graphics

But it says in the above answer that it wants x>0,t>0, which is why I gave it the assumptions to help it, but then it returns undefined.

Something seems to have gone wrong in V 12 DSolve here, or may be in the Integrate? I do not know.

Do others see the same result on V 12?. Answer given by V 11.3 is the correct one.

Any workaround for V 12 to make it give same answer as V 11.3?

Having restrictions on library usage yet providing a workaround for abusing library features

In terms of design, I thought that having concrete restrictions on the use of your library is a must, so you can guide the user to the intended and most optimal use of your library, but at the same time I feel like next to it, having a way to overcome these restrictions is also a good idea for providing the needed freedom in certain cases.

For example, let’s say I have a class which I mark as final because I don’t want client code inheriting from it, but at the same time, I want to have this workaround.

I came up with the following example code for the case with the final specifier.

#ifdef OPEN_TO_MODIFY     #define FINAL     #else         #define FINAL final #endif  class Foo FINAL { }; 

You will need to just define the OPEN_TO_MODIFY macro in your code and the classes won’t be final anymore, so you can freely inherit from them and abuse them as you want.

Is this design choice a bad practice (having concrete restrictions yet providing a workaround)

Work-around to get USB-C headset to work for calls (in Android smartphones)?

It is an interesting, albeit frustrating, phenomenon of late that manufacturers of soft- and hardware these days (including Huawei, Samsung and apparently also Google) release new products which do not function as advertized:

I use my usb-c setup for mostly listening to hi-res music, it’s annoying when I get a phone call and I have to disconnect my USB-c headphones to answer the call. Seriously Samsung needs to get there head out of the ass and fix this problem. How can every other flagship phone handle this including the OnePlus 6.

and

bump. So I did some bumming around. I don’t think it’s the equalizer that’s the problem. I think the phone app is incapable of routing calls through USB-C.

and

Google acknowledges Pixel 2 USB-C headphone adapter issue, says fix coming

and

It’s 2018 and USB Type-C is still a mess

and

How USB Type-C Has Failed Android Smartphone Users

Here’s what I’m confronted with: Huawei P10 with up-to-date software as of 3 Sep 2018, build nr. VTR-L09 8.0.0.375(C432) and “Dialer” app/process (?) version nr. 8.1.0.301 and Huawei Active Noise Cancel(l)ing Earphones 3 (cm-Q3) where sound works and calls through other apps like WhatsApp works but not through the standard telephone app. Any ideas on how to route standard phone calls through another (trustworthy…) app?

Other than finding a viable work-around all I can do is to hope that a fix will percolate through eventually through an update…

Please help to suggest workaround to prevent docker from this security issue while still not have update patch

According to this news from these URL.

https://www.bleepingcomputer.com/news/security/unpatched-flaw-affects-all-docker-versions-exploits-ready/

As the System Administrator Roles. I update Security Patch for OS Ubuntu 18.04.2 and Check Network / Firewall already. Our Docker version is 18.09.06. However I would like to find the best way to prevent docker’s system from this security issue until Security Patch is release.

Thank you.

Whatsapp workaround?

What I have:
– I don’t want to install Whatsapp on my phone because I don’t want it to access my personal data.
– There’s an organisation that requires me to use Whatsapp to communicate with them.
– These two statements are mutually exclusive….

What I want:
– Is there any way for me to use Whatsapp without installing it on my phone? (I already have a Whatsapp user account.)
– Alternatively, is there a way to install and use Whatsapp without giving it access to all my data? (Contacts, calendar, camera, photos, etc etc.) I use Android 7.1.2 because there’s no newer ROM for my phone.

I realize this might be offensive to some users (“use it or don’t!”) but please look past that. I’m trying to satisfy competing demands here.

Uploading of backdoor results in the server removing file extensions. Any workaround?

I am totally new within the scene of information security, but find it extremely interesting and thus taking a course at my university, where we have to break into a website/webserver. The website is an image sharing website. The website is badly secured and I am looking for a way to upload my php backdoor created through weevely.

I can without problems upload a php file to the server. The problem is that the server automatically removes the file extensions, which makes it impossible for me to access through weevely (or so I think). Is there anyway to access a backdoor, when the file extensions are missing or is there a workaround?

Apologize for the rookie question!

Thanks How the upload folder looks like

Buffer overflow return address with null byte, workaround

Practising BO using Free Float FTP Server 1.0 on Windows 7 SP1, done simple jmp esp examples on Win XP where system DLL are without rebase or ASLR, trying to write one for Win7 where I haven’t got any system DLL with rebase or ASLR disabled, I can still exploit it but it won’t survive reboot, so I’m very much left with opcodes from the FTPServer.exe but the problem is that they all use a low stack addresses (0x0040xxxx) , so they all end with NULL byte (eg, \xce\x11\x40\x00 ) and hence terminate my exploit. My question is what are the options, if any to workaround the NULL byte in address I want to use, more specifically I want to know whenever there is an option to use NULL byte at the end of return address if it is listed as a bad character?

extfs_fsck crash on macos 10.14.4. Any workaround or fix?

I am trying to mount an external HD with extfs, but apparently the latest unmount was non-successful, and now the disk requires an automatic fsck. When macos tries to perform the fsck, this happens

Process:               fsck_exfat [47683] Path:                  /System/Library/Filesystems/exfat.fs/Contents/Resources/fsck_exfat Identifier:            fsck_exfat Version:               90.200.1 Code Type:             X86-64 (Native) Parent Process:        diskarbitrationd [66] Responsible:           fsck_exfat [47683] User ID:               0  Date/Time:             2019-04-05 00:13:11.857 +0100 OS Version:            Mac OS X 10.14.3 (18D109) Report Version:        12 Bridge OS Version:     3.3 (16P3133) Anonymous UUID:        972E6B24-EE1F-B5A0-2545-E9EE3AE52D78   Time Awake Since Boot: 980000 seconds  System Integrity Protection: enabled  Crashed Thread:        0  Dispatch queue: com.apple.main-thread  Exception Type:        EXC_CRASH (SIGABRT) Exception Codes:       0x0000000000000000, 0x0000000000000000 Exception Note:        EXC_CORPSE_NOTIFY  Application Specific Information: dyld3 mode Assertion failed: (result->data == NULL), function fsck_exfat_cache_recycle, file /BuildRoot/Library/Caches/com.apple.xbs/Sources/exfat/exfat-90.200.1/fsck/fsck_exfat_cache.c, line 248.   Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0   libsystem_kernel.dylib          0x00007fff6ff9d23e __pthread_kill + 10 1   libsystem_pthread.dylib         0x00007fff70053c1c pthread_kill + 285 2   libsystem_c.dylib               0x00007fff6ff061c9 abort + 127 3   libsystem_c.dylib               0x00007fff6fece868 __assert_rtn + 320 4   fsck_exfat                      0x00000001099961a1 0x10998e000 + 33185 5   fsck_exfat                      0x000000010999634e 0x10998e000 + 33614 6   fsck_exfat                      0x00000001099953ff 0x10998e000 + 29695 7   fsck_exfat                      0x0000000109993068 0x10998e000 + 20584 8   fsck_exfat                      0x0000000109993461 0x10998e000 + 21601 9   libdyld.dylib                   0x00007fff6fe5ded9 start + 1  Thread 1: 0   libsystem_pthread.dylib         0x00007fff700503f8 start_wqthread + 0 1   ???                             0x0000000054485244 0 + 1414025796  Thread 0 crashed with X86 Thread State (64-bit):   rax: 0x0000000000000000  rbx: 0x00000001146785c0  rcx: 0x00007ffee6271998  rdx: 0x0000000000000000   rdi: 0x0000000000000507  rsi: 0x0000000000000006  rbp: 0x00007ffee62719d0  rsp: 0x00007ffee6271998    r8: 0x00000000000000f8   r9: 0xcccccccccccccccd  r10: 0x0000000000000000  r11: 0x0000000000000206   r12: 0x0000000000000507  r13: 0x0000000109ac9000  r14: 0x0000000000000006  r15: 0x000000000000002d   rip: 0x00007fff6ff9d23e  rfl: 0x0000000000000206  cr2: 0x00007fffa2c37188  Logical CPU:     0 Error Code:      0x02000148 Trap Number:     133   Binary Images:        0x10998e000 -        0x109999fff  fsck_exfat (90.200.1) <5040465B-D4D0-3486-8BC0-51662BCFAD1D> /System/Library/Filesystems/exfat.fs/Contents/Resources/fsck_exfat        0x1145c2000 -        0x114640a87  dyld (655.1) <3EBA447F-A546-366B-B302-8DC3B21A3E30> /usr/lib/dyld     0x7fff42bd5000 -     0x7fff43022fef  com.apple.CoreFoundation (6.9 - 1562) <02A2C178-9FF6-385C-A9C5-7F4FC9D66311> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation     0x7fff6cf1f000 -     0x7fff6cf20ff7  libDiagnosticMessagesClient.dylib (107) <15210AC0-61F9-3F9D-A159-A009F62EB537> /usr/lib/libDiagnosticMessagesClient.dylib     0x7fff6d2d1000 -     0x7fff6d2d2ffb  libSystem.B.dylib (1252.200.5) <C6201660-5E17-397D-BA21-C503420CD706> /usr/lib/libSystem.B.dylib     0x7fff6d52b000 -     0x7fff6d582ff7  libc++.1.dylib (400.9.4) <B260AC33-EB9A-30C6-8746-D011B3B02B08> /usr/lib/libc++.1.dylib     0x7fff6d583000 -     0x7fff6d598fff  libc++abi.dylib (400.17) <446F4748-8A89-3D2E-AE1C-27EEBE93A8AB> /usr/lib/libc++abi.dylib     0x7fff6e1e7000 -     0x7fff6e44affb  libicucore.A.dylib (62109.0.1) <FEB89BD3-79C4-3208-A754-7E6BC4D38548> /usr/lib/libicucore.A.dylib     0x7fff6ed79000 -     0x7fff6f4fffe7  libobjc.A.dylib (750.1) <804715F4-F52D-34D0-8FEC-A25DC08513C3> /usr/lib/libobjc.A.dylib     0x7fff6fc5c000 -     0x7fff6fc6effb  libz.1.dylib (70.200.4) <15F7B40A-424C-33BB-BF2C-7E8195128B78> /usr/lib/libz.1.dylib     0x7fff6fcdf000 -     0x7fff6fce3ff3  libcache.dylib (81) <704331AC-E43D-343A-8C24-39201142AF27> /usr/lib/system/libcache.dylib     0x7fff6fce4000 -     0x7fff6fceeff3  libcommonCrypto.dylib (60118.220.1) <9C865644-EE9A-3662-AB77-7C8A5E561784> /usr/lib/system/libcommonCrypto.dylib     0x7fff6fcef000 -     0x7fff6fcf6fff  libcompiler_rt.dylib (63.4) <817772E3-E836-3FFD-A39B-BDCD1C357221> /usr/lib/system/libcompiler_rt.dylib     0x7fff6fcf7000 -     0x7fff6fd00ff3  libcopyfile.dylib (146.200.3) <5C5C4F35-DAB7-3CF1-940F-F47192AB8289> /usr/lib/system/libcopyfile.dylib     0x7fff6fd01000 -     0x7fff6fd85fdf  libcorecrypto.dylib (602.230.1) <C78D1A87-5543-3561-BEB4-3B480BA94ECB> /usr/lib/system/libcorecrypto.dylib     0x7fff6fe0c000 -     0x7fff6fe46ff7  libdispatch.dylib (1008.220.2) <2FDB1401-5119-3DF0-91F5-F4E105F00CD7> /usr/lib/system/libdispatch.dylib     0x7fff6fe47000 -     0x7fff6fe76ff3  libdyld.dylib (655.1) <90C801E7-5D05-37A8-810C-B58E8C53953A> /usr/lib/system/libdyld.dylib     0x7fff6fe77000 -     0x7fff6fe77ffb  libkeymgr.dylib (30) <A4EFD9A4-2EF3-3E18-B325-F527E3821939> /usr/lib/system/libkeymgr.dylib     0x7fff6fe85000 -     0x7fff6fe85ff7  liblaunch.dylib (1336.240.2) <D5F0014D-CF46-3B04-9DE0-A1466DA14A2C> /usr/lib/system/liblaunch.dylib     0x7fff6fe86000 -     0x7fff6fe8bfff  libmacho.dylib (921) <6ADB99F3-D142-3A0A-B3CE-031354766ACC> /usr/lib/system/libmacho.dylib     0x7fff6fe8c000 -     0x7fff6fe8effb  libquarantine.dylib (86.220.1) <58524FD7-63C5-38E0-9D90-845A79551C14> /usr/lib/system/libquarantine.dylib     0x7fff6fe8f000 -     0x7fff6fe90ff3  libremovefile.dylib (45.200.2) <BA53CA8A-9974-3A43-9265-B110B1AE470F> /usr/lib/system/libremovefile.dylib     0x7fff6fe91000 -     0x7fff6fea8ff3  libsystem_asl.dylib (356.200.4) <33C62769-1242-3BC1-9459-13CBCDECC7FE> /usr/lib/system/libsystem_asl.dylib     0x7fff6fea9000 -     0x7fff6fea9fff  libsystem_blocks.dylib (73) <152EDADF-7D94-35F2-89B7-E66DCD945BBA> /usr/lib/system/libsystem_blocks.dylib     0x7fff6feaa000 -     0x7fff6ff32fff  libsystem_c.dylib (1272.200.26) <D6C701A2-9F17-308D-B6AC-9E17EF31B7DF> /usr/lib/system/libsystem_c.dylib     0x7fff6ff33000 -     0x7fff6ff36ff7  libsystem_configuration.dylib (963.200.27) <94898525-ECC8-3CC9-B312-CBEAAC305E32> /usr/lib/system/libsystem_configuration.dylib     0x7fff6ff37000 -     0x7fff6ff3aff7  libsystem_coreservices.dylib (66) <10818C17-70E1-328E-A3E3-C3EB81AEC590> /usr/lib/system/libsystem_coreservices.dylib     0x7fff6ff3b000 -     0x7fff6ff41ffb  libsystem_darwin.dylib (1272.200.26) <07468CF7-982F-37C4-83D0-D5E602A683AA> /usr/lib/system/libsystem_darwin.dylib     0x7fff6ff42000 -     0x7fff6ff48ff7  libsystem_dnssd.dylib (878.240.1) <5FEA5E1E-E80F-3616-AD33-8E936D61F31A> /usr/lib/system/libsystem_dnssd.dylib     0x7fff6ff49000 -     0x7fff6ff95ff3  libsystem_info.dylib (517.200.9) <54B65F21-2E93-3579-9B72-6637A03245D9> /usr/lib/system/libsystem_info.dylib     0x7fff6ff96000 -     0x7fff6ffbeff7  libsystem_kernel.dylib (4903.241.1) <CA10BC3A-5B09-32CE-B74F-BAD01755AA37> /usr/lib/system/libsystem_kernel.dylib     0x7fff6ffbf000 -     0x7fff7000aff7  libsystem_m.dylib (3158.200.7) <AF25F8E8-194C-314F-A2D3-A424853EE796> /usr/lib/system/libsystem_m.dylib     0x7fff7000b000 -     0x7fff7002fff7  libsystem_malloc.dylib (166.220.1) <4777DC06-F9C6-356E-82AB-86A1C6D62F3A> /usr/lib/system/libsystem_malloc.dylib     0x7fff70030000 -     0x7fff7003bff3  libsystem_networkextension.dylib (767.240.1) <4DB0D4A2-83E7-3638-AAA0-39CECD5C25F8> /usr/lib/system/libsystem_networkextension.dylib     0x7fff7003c000 -     0x7fff70043fff  libsystem_notify.dylib (172.200.21) <65B3061D-41D7-3485-B217-A861E05AD50B> /usr/lib/system/libsystem_notify.dylib     0x7fff70044000 -     0x7fff7004dfef  libsystem_platform.dylib (177.200.16) <83DED753-51EC-3B8C-A98D-883A5184086B> /usr/lib/system/libsystem_platform.dylib     0x7fff7004e000 -     0x7fff70058fff  libsystem_pthread.dylib (330.230.1) <80CC5992-823E-327E-BB6E-9D4568B84161> /usr/lib/system/libsystem_pthread.dylib     0x7fff70059000 -     0x7fff7005cff7  libsystem_sandbox.dylib (851.230.3) <D6469A17-C13C-3538-A300-D6517BB7F249> /usr/lib/system/libsystem_sandbox.dylib     0x7fff7005d000 -     0x7fff7005fff3  libsystem_secinit.dylib (30.220.1) <5964B6D2-19D4-3CF9-BDBC-4EB1D42348F1> /usr/lib/system/libsystem_secinit.dylib     0x7fff70060000 -     0x7fff70067ff7  libsystem_symptoms.dylib (820.237.2) <487E1794-4C6E-3B1B-9C55-95B1A5FF9B90> /usr/lib/system/libsystem_symptoms.dylib     0x7fff70068000 -     0x7fff7007dff7  libsystem_trace.dylib (906.220.1) <4D4BA88A-FA32-379D-8860-33838723B35F> /usr/lib/system/libsystem_trace.dylib     0x7fff7007f000 -     0x7fff70084ffb  libunwind.dylib (35.4) <EF1A77FD-A86B-39F5-ABEA-6100AB23583A> /usr/lib/system/libunwind.dylib     0x7fff70085000 -     0x7fff700b5fff  libxpc.dylib (1336.240.2) <EE0CDA53-6FF9-3B4E-A571-335A5FF6B6F4> /usr/lib/system/libxpc.dylib  External Modification Summary:   Calls made by other processes targeting this process:     task_for_pid: 0     thread_create: 0     thread_set_state: 0   Calls made by this process:     task_for_pid: 0     thread_create: 0     thread_set_state: 0   Calls made by all processes on this machine:     task_for_pid: 602965     thread_create: 0     thread_set_state: 0  VM Region Summary: ReadOnly portion of Libraries: Total=234.6M resident=0K(0%) swapped_out_or_unallocated=234.6M(100%) Writable regions: Total=356.0M written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=356.0M(100%)                                  VIRTUAL   REGION  REGION TYPE                        SIZE    COUNT (non-coalesced)  ===========                     =======  =======  Dispatch continuations            24.0M        2  Kernel Alloc Once                    8K        2  MALLOC                           276.2M       23  MALLOC guard page                   16K        5  MALLOC_LARGE (reserved)           46.3M        2         reserved VM address space (unallocated) STACK GUARD                       56.0M        3  Stack                             8712K        3  VM_ALLOCATE                          4K        2  __DATA                            4664K       44  __LINKEDIT                       216.1M        4  __TEXT                            18.5M       44  __UNICODE                          564K        2  shared memory                        8K        3  ===========                     =======  =======  TOTAL                            650.8M      126  TOTAL, minus reserved VM space   604.5M      126   

It brings the whole system down with it. The mac reboots.

Is this a known issue? I could not find anything googling. Do you have a workaround for it?