[Firebird 2.1] Statement zu einer offenen Transaktion finden

[mkinzler]

Zitat:

So erkläre ich mir das jedenfalls. Was ich allerdings 'gewöhnungsbedürftig' finde, ist die Tatsache, das eine Query offensichtlich eine Transaktion öffnet. Aber gut, wenn das so ist.

Das ist halt das Tribut was man der Transaktionssteuerung von FB zollen muss

[Elvis]

Zitat:

Zitat von alzaimar

Die Tipps aller und speziell die Query von Elvis haben mir geholfen...

:-)
btw: diese Art von anonymen Fire-and-Forget Code-Block, der eine Ergebnismenge liefert, meinte ich im anderen Thread als einer der Vorteile von FB.

Zitat:

So erkläre ich mir das jedenfalls. Was ich allerdings 'gewöhnungsbedürftig' finde, ist die Tatsache, das eine Query offensichtlich eine Transaktion öffnet. Aber gut, wenn das so ist.

Naja, innerhalb eines Webrequest, würdest du doch gerne alle Infos atomisch haben, oder? Also nicht dass eine Hälfte der Antwort mit anderen Werten generiert wird.
Firebird nimmt Transaktionen halt absolut wörtlich. Kann nervig sein. Aber unterm Strich wäre ich oft froh wenn andere (teure!) DBMS' auch nur halbwegs so viel von Record-Versionierung verstehen würden.

Zitat:

PS: Ein sehr hübsches Monitoring-Tool ist von 'Sinática'. Ich mach da jetzt keine Werbung, weil das Tool nicht sonderlich viele Features hat, aber schön anzusehen ist es allemal. Es lohnt -aus rein ästhetischen Gesichtspunkten- sich das Teil mal anzuschauen.

Für genau den Fall reicht mir so eine Query wie weiter oben.

Wer mehr, präzises Monitoring will muss eben die Maschine untendrunter wegnehmen:
Wir haben (fast) alle unsere in-house Server virtualisiert. Und die Software von VMWare erlaubt es auch wunderschön zu sehen welcher Server wann wie welche Peaks in Disk I/O, Speicher, aktiver Thread-Zahl, CPU Auslastung etc hat.

[alzaimar]

Bleibt festzuhalten, das man die (Transaktions-)Philosophie von Firebird verstehen muss, um damit gut und performant zu arbeiten. Wenn man sich an die Regeln hält, scheint es ja Spass zu machen.

Allerdings ist der eigentliche Hammer der hier:

Nachdem ich also diese blöde Pufferung endlich stabil und performant hinbekommen habe....

... wurde sie vom Kunden gekickt.

:wall:

[mkinzler]

Zitat:

Nachdem ich also diese blöde Pufferung endlich stabil und performant hinbekommen habe....

... wurde sie vom Kunden gekickt.

Wegen den Performence-Problemen oder hatte das andere Gründe?

[alzaimar]

Es gab ja keine Performanceprobleme mehr: Das System hat selbst einen simulierten Ausfall von einer Woche mit Nonstop-Befeuerung des Clients und gleichzeitigem Puffern der Daten anstandslos hingenommen. Nach meinem Redesign des kompletten Apparates (aus Zeitgründen habe ich keine bessere Pufferung On-Demand gebaut, sondern das existierende System verwendet) ist die Performance um den Faktor 2 gestiegen...

Allerdings ist denen klar geworden, das ihr Client in die Knie geht, wenn er derart massiv mit Daten befeuert wird *MitderFaustaufdenTischTrommelundLachendAmBodenLie g*.

An sich ist das schon peinlich (für meinen Auftraggeber, dessen Kunde den Rückzieher gemacht hat), aber es ist nicht wild: Ich werde nach Aufwand bezahlt und nicht, ob der Kunde das abnimmt...

[mquadrat]

Insofern kannst du das unter dem Punkt "bezahltes Lernen" abhaken ;)

[mschaefer]

In dem Zusammenhang stellt sich mir die Frage: Wie kann ich noch offene Transaktionen serverseitig löschen ?

Grüße in die Runde // Martin