Soci (Soczó Zsolt) szakmai blogja

2009.08.04.

A jitter huncutságai

Filed under: .NET,C#,CLR,Szakmai élet — Soczó Zsolt @ 12:57

Érdekes és furcsa dolgok történnek néha a .net jitter miatt, ami nem nagyon fordul elő nem managelt környezetben.

Itt ez a kis factoryka részlet:

public IBroker GetBroker()
{
if (broker == null)
{
switch (BrokerMode)
{
case BrokerMode.Simulated:
broker = new BrokerSimulated();
break;
case BrokerMode.IB:
broker = IBBroker.Instance;
break;
}
}
return broker;
}

Amikor meghívtam ezt a sort:

BrokerFactory.Factory.GetBroker().SetInitialEquity(20000);

akkor furcsamód lefutott az élő broker, az IBBroker konstruktora. Pedig NEM az az ág futott le a switchben. Valószínűleg az történt, hogy a jitter hozzáért az IBBroker osztályhoz, ez pedig törvényszerűen kiváltotta a statikus konstruktor lefutását.

A megoldás pofonegyszerű (ha ismerjük az okot :), ki kell emelni a beteg típusra hivatkozást egy külön metódusba. Mivel a jitter metódusonként dolgozik, így addig tényleg nem nyúl a típusunkhoz, míg tényleg nem használjuk:

public IBroker GetBroker()
{
if (broker == null)
{
switch (BrokerMode)
{
case BrokerMode.Simulated:
broker = new BrokerSimulated();
break;
case BrokerMode.IB:
broker = CreateIBBroker();
break;
}
}
return broker;
}

private static IBBroker CreateIBBroker()
{
return IBBroker.Instance;
}

Deadlock bulk load során

Párhuzamos bulk betöltések esetén deadlockolhatnak egymással a másoló szálak, főleg, ha vannak FK-ek a táblákon.

Sokféle megoldás adható a problémára.
1. Átmeneti táblába töltünk, amin nincsenek indexek és fk-k.
2. Lekezeljük a deadlockot, és ismétlünk.
3. tablock-kal töltünk be, ezzel azonban súlyosan visszavethetjük a párhuzamosságot.
Ezt ki lehet kényszeríteni központilag is:
EXEC sp_tableoption ‘Tick’, ‘table lock on bulk load’, ‘1’

Nekem ez jó volt, mert nálam az adatforrás volt lassú 1 szálon, ezért kellett 40, az SQL betöltések sorosítva is elég gyorsak, és nincs deadlock.

Powered by WordPress