gubus 2.0

TransactionScope + System.Data.SQLClient – timeout bug

Írta: gubus on 2008. 08. 29.

Érdekes hibába futottam bele pár hete:

Issue with System.Transactions, SqlConnection and Timeout

How to Use System.Data with System.Transactions and Maintain Atomicity and Data Consistency

Szituáció: Egy folyamat a new TransactionScope(..)- hívással megnyitja a tranzakciót, majd folyamat elkezdi a scope-on belül az SQL Server adatbázisokat matatni.

Abban az esetben, ha a matatás folyamat lassú, és nem jut el tranzakció timeout időn belül a TransactionScope Complete() hívásáig, akkor:

- a timeout leteltekor az SqlConnection – transaction kötés megszűnik,

- a kapcsolat tranzakció nélkül lóg a levegőben, auto commit módban került, vagyis ezután minden rajta keresztül végzett művelet commitolva lesz,

- a matatás végeztekor a folyamat meghívja a TransactionScope Complete() hívást, ami Exception-nel jelzi, hogy timeout van, és visszavonja timeout letelte előtt végzett műveleteket.

Következmény: a timeout után végzett módosítások nem kerülnek visszavonásra.

A hibát észrevették, javították, de úgy, hogy a javított viselkedést külön kell aktiválni a connection string-ben megadott transaction binding=explicit Unbind; paraméterrel.

Mely CLR verziókban támogatott:

Version transaction binding supported? Comment
2.0.50727.42 - RTM
2.0.50727.832 - KB928365 – (RTM után, de még SP1 előtt)
2.0.50727.1433 + .NET 2.0 SP1
2.0.50727.3053 + .NET 2.0 SP2

Illetve Florin Lazar szerint:

“Hopefully, the default behavior will change to explicit unbind in the future releases (non-SP) of .Net Framework.”

Mi a tranzakció timeout értéke?

A Machine.Config-ban a configuration/system.transactions/machineSettings elemnél a maxTimeout a gépen belül beállítható max timeout-ot adja meg, ami alapesetben 10 perc.

Ezen belül mozoghat alkalmazásonként az App.Config-ban a configuration/system.transactions/defaultSettings elemnél a timeout paraméter, mely alapesetben 1 perc.

Tehát alapértelmezett esetben 1 perc .

Posted in .NET, SQL Server | Leave a Comment »

Raymond úr tanácsai magyarul :)

Írta: gubus on 2008. 08. 25.

http://www.raymond.cc/blog/hu/

ISO-8859-1 vagy ISO-8859-2 kódlappal látszik jól, kolosszális!

Posted in Off | Leave a Comment »

SSIS csomag ütemezése – DSCEXEC

Írta: gubus on 2008. 08. 19.

Ezidáig az SSIS csomagokat az SQL Server Agent alatt a Job / XX Step beállításánál SSIS Package-ként ütemeztük: készült SQL Server Agent Proxy, aminek a felhasználójának nevében futott a csomag, meg kellett adni a felületen a csomagot, config beállítást, meg a maradék cuccokat.

Két dolog nem passzolt ezzel a felállással:

- A fejlesztői/teszt/üzemi futtatást eltért: a nehezen lehet ugyanúgy futtatni, egyik helyen elír valamit az ember, akkor azt nem veszi észre. Reprodukálni is nehéz: a csak SQL Agent alatt hibás csomagok kint, Agent nélkül nem produkálják a hibát (ami legtöbbször hibás, vagy hiányzó környezeti beállítás miatt van)

- hibakezelés: ha az SQL Server Agent a csomag betöltése, vagy futtatása során hibát, vagy warningot talált, akkor a hibaüzenetek egy része (vagy a teljes) az Agent alól nem látszik. A csomagon belüli logolás pedig a betöltési problémákat nem tartalmazza például.

Helyette egyszerűbb Windows parancssorból közvetlenül hívni a DTSEXEC programot: az SQL Server Agent Job készítésekor az Operating System  (cmdExec) típust választani, és beírni a DTSEXEC hívást. A konzol kimenetét fájlba lehet irányítani, így a DTSEXEC konzolra írt üzeneteit vissza lehet keresni. Így ugyanazzal a scripttel lehet Agent alól, és simán is futatni a csomagot, ha kint megy ugyanazokkal a környezeti feltételekkel, akkor Agent alatt is fog.

Linkek:

SSIS and SQL Server Agent

SSIS and SQL Server Agent – Choosing the Right Job Step Type

KB: An SSIS package does not run when you call the SSIS package from a SQL Server Agent job step

Posted in SQL Server | Leave a Comment »

links for 2007-10-16

Írta: gubus on 2007. 10. 16.

Posted in Links | Leave a Comment »

WCF – client IP address

Írta: gubus on 2007. 10. 11.

Most szembesültem azzal, hogyha van WCF alatt egy webszolgáltatás, akkor az jelenleg nem tudja megmondani, hogy milyen IP-ről hívták meg. Hát basszus, a log-ba akkor most mit tegyek. Értem én, hogy absztrakció, meg itt rétegek vannak, de a tudomány oltárán azért nem kellene feláldozni. :)

Következő verzióban viszont benne lesz.

 Can I get the IP address of a client connecting to my service?
http://blogs.msdn.com/drnick/archive/2007/05/16/client-ip-address.aspx

More about Client IP Addresses
http://blogs.msdn.com/drnick/archive/2007/09/10/more-about-client-ip-addresses.aspx

Client IP addresses in Orcas
http://blogs.msdn.com/phenning/archive/2007/08/08/remoteendpointmessageproperty-in-wcf-net-3-5.aspx

Posted in WCF | Leave a Comment »

The Windows Server 2003 /3GB switch is not supported in Windows SharePoint Services 2.0 or in later versions or in SharePoint Portal Server 2003 SP2 or in later versions

Írta: gubus on 2007. 10. 2.

Jó tudni: hivatalosan nem támogatott a /3GB  és a SharePoint.

http://support.microsoft.com/kb/933560

Posted in SharePoint, Windows | Leave a Comment »

WCF WSDL – <xsd:import

Írta: gubus on 2007. 08. 12.

WCF alatt a webszolgáltatások WSDL leírója nem mindig egy fájlból áll elő: ilyenkor a gyökér WSDL-en (http://localhost:92/Users/Service.svc?wsdl) belül további hivatkozás is lehet más fájlokra.

Pl.: 

<xsd:import schemaLocation=”http://localhost:92/Users/Service.svc?xsd=xsd0

A megoldás szabványos, viszont a régi kliensek nem mindig tudják ezt kezelni, ilyenkor célszerű síkba, egy fájlba kiteríteni a WSDL-t. Christian Weyer-nél van egy megoldás, amivel a generált WSDL nem szakad szét több darabba: Improving WCF Interoperability: Flattening your WSDL

A beszerelésnél ott szúrtam el, hogy a config-ban az <endpoint-nál a bindingNamespace-t meg kell adni, és annak a ServiceContract / ServiceBehavior attribútumoknál megadott értéket kell adni.

Posted in WCF | Leave a Comment »

ABEV és ekon telepítése és használata Windows Vista alatt

Írta: gubus on 2007. 08. 2.

Posted in .NET | Leave a Comment »

SWA + .NET + interoperabilitás

Írta: gubus on 2007. 06. 9.

Munkahelyemen sikerült kifogni egy érdekes interfész csatlakozást. Hivatali kapu a neve, a cucc Java-ban készült, AXIS 1 könyvtár felhasználásával, SOAP over HTTP; van egy szerver, oda kell a kéréseket küldeni HTTP-n. Van WSDL, ami egyáltalán nem használható, de legtöbb funkcióhoz legalább van XSD.

A problémás a csatolt dokumentumok kezelése: az űrlapok letöltésekor, és a válaszüzenetek küldésekor csatolt doksiként megy a fájl a SOAP boríték mellett. A  használt mód: http://www.w3.org/TR/SOAP-attachments , vagyis az SWA. Látni, hogy nem W3C hivatalos ajánlás, csak Note szinten van jegyezve.

MS (.NET) oldalon csak a DIME (WSE2), MTOM (WSE3, WCF) módszerek van támogatva csatolás kezelésre, az SWA nincs implementálva. MTOM a hivatalos W3C szabvány, DIME az MS saját megoldása, az SWA pedig nem MS környezetben terjedt el.

Az SWA nem bonyolult:

“The specification combines specific usage of the Multipart/Related MIME media type (RFC 2387) and the URI schemes discussed in RFC 2111 and RFC2557 for referencing MIME parts.”

Letöltéskor A SOAP üzenet helyet egy MIME üzenetet kell parsolni, majd abból SOAP üzenetet és a csatolt fájlt kivenni, feltöltéskor pedig egy MIME  üzenetet kell a SOAP üzenetből és a fájlból előállítani.

MIME parsolásra és előállításra könyvtár: CodeProject: Advanced MIME Parser/Creator/Editor

Legutolsó verziójának letöltése: http://www.lumisoft.ee/lsWWW/Download/Downloads/Net/

A LumiSoft Net library elég sok dolgot tartalmaz:, pl.: pop3 client+server, imap client+server, smtp client+server, a help-je elég beszédes: http://www.lumisoft.ee/lsWWW/Download/Downloads/Net/Help/Index.html

Egyéb régi, de kapcsolódó cikkek:

Finding a .NET implementation of SOAP Messages with Attachments

Web Services, Opaque Data, and the Attachments Problem

Mick Tech.Net Magazinban publikált MIME sorozata

Posted in .NET | Leave a Comment »

ABEV eltávolítás

Írta: gubus on 2007. 06. 9.

Varánusznak már volt egy szösszenete a témában (SzJA-bevallás elektronikusan), kiegészíteném:

(Odatesz rendesen, Petert biztos örülne a színezésnek :))

abev

Őnagysága a HKEY_CURRENT_USER\Software\Abev6\SetupPath alatt tárolja a registry-ben, hogy hova lett telepítve. Mivel ez a kulcs a felhasználóhoz kötött ágon van, ezért csak azzal felhasználóval lehet  leszedni, aki telepítette. (Az is érdekes, ha már a Program Files alá teszi magát, akkor miért oda menti az adatokat (pl nem admin fiókkal mi lesz).)

Posted in .NET | 1 Comment »