I am using igniteDataStreamer and would like to know if it is possible to use transactions from closures.
Unfortunately, when running from different IgniteDataStreamer threads for the same record to update in the cache(receive() method in StreamReceiver), Ignite does not throw any TransactionOptimisticException even though CacheConfiguration atomicityMode is TRANSACTIONAL.
try (Transaction t = ignite.transactions().txStart(TransactionConcurrency.OPTIMISTIC, TransactionIsolation.SERIALIZABLE)) {
try {
cache.putAll(update);
t.commit();
catch (TransactionOptimisticException toe) {
LOG.error("TransactionOptimisticException Could not put all the profiles",toe);
}
}
Data streamer is not transactional. To execute updates in a single transaction, they must be initiated on the same node and by the same thread. For more details and examples read here: https://apacheignite.readme.io/docs/transactions
Related
Support for transactional streams seems to have been recently implemented but due to its newness, there are not many code examples.
Could someone show an example of a transactional stream that does a series of database inserts and then returns some value on success, but with a midstream checkpoint in between inserts that tests some condition and might roll back the transaction and return different values depending on the checkpoint result?
Reactive transactions follow the same pattern as imperative ones:
A transaction is started before running any user-space commands
Run user-space commands
Commit (or rollback)
A few aspects to note here: A connection is always associated with a materialization of a reactive sequence. What we know from a Thread-bound connection that is bound to an execution in imperative programming translates to an materialization in reactive programming.
So each (concurrent) execution gets a connection assigned.
Spring Data R2DBC has no support for savepoints. Take a look at the following code example that illustrates a decision to either commit or rollback:
DatabaseClient databaseClient = DatabaseClient.create(connectionFactory);
TransactionalOperator transactionalOperator = TransactionalOperator
.create(new R2dbcTransactionManager(connectionFactory));
transactionalOperator.execute(tx -> {
Mono<Void> insert = databaseClient.execute("INSERT INTO legoset VALUES(…)")
.then();
Mono<Long> select = databaseClient.execute("SELECT COUNT(*) FROM legoset")
.as(Long.class)
.fetch()
.first();
return insert.then(select.handle((count, sink) -> {
if(count > 10) {
tx.setRollbackOnly();
}
}));
}).as(StepVerifier::create).verifyComplete();
Notable aspects here are:
We're using TransactionalOperator instead of #Transactional.
The code in .handle() calls setRollbackOnly() to roll back the transaction.
Using #Transactional, you would typically use exceptions to signal a rollback condition.
I have a WCF service that has some operations that may take long...
The client receives a TimeoutException, but the server continues executing after the long operation.
Server:
public void doSomeWork(TransmissionObject o) {
doDBOperation1(o); //
doDBOperation2(o); // may result in TimeoutException on client
doDBOperation3(o); // it continues doing DB operations. The client is unaware!
}
Client:
ServiceReference.IServiceClient cli = new ServiceReference.IServiceClient("WSHttpBinding_IService","http://localhost:3237/Test/service.svc");
int size = 1000;
Boolean done = false;
TransmissionObject o = null;
while(!done) {
o = createTransmissionObject(size);
try {
cli.doSomeWork(o);
done = true;
}catch(TimeoutException ex) {
// We want to reduce the size of the object, and try again
size--;
// the DB operations in server succeed, but the client doesn't know
// this makes errors.
}catch(Exception ex) { ... }
}
Since the server is performing some DB operations, I need to detect the timeout on the server side to be able to rollback the DB operations.
I tried to use Transactions with [TransactionFlow], TransactionScope, etc, on the client side, but the DB operations on the server are using Stored Procedures that are NESTED!!, therefore I cannot use distributed transactions. (I receive an SqlException saying: Cannot Use SAVE TRANSACTION Within A Distributed Transaction.). If I use simple SPs (that are not nested), then the solution with the transactions works fine.
My Question:
How can I detect the TimeoutException, but on the server side? I guess is something related to the proxy status... or probably some Events that can be captured by the server.
I'm not sure if handling the transaction on the server side is the correct solution..
Is there a pattern to solve this problem?
Thanks!
Instead of waiting for an operation to time out, you may consider using asynchronous operations, as in this blog post: http://www.danrigsby.com/blog/index.php/2008/03/18/async-operations-in-wcf-event-based-model/
The idea is that you precisely expect an operation to take some time. The server will signal to the client when the job is finished.
We have implemented an auditing system via NHibernate event listeners. In our listener, we track all changes and write them out to our audit tables. To try and maximize performance, we have used Guid's for our audit tables so that we can batch our updates as much as possible.
We are writing out updates to a "child session" which we get like this:
protected ISession GetSession(AbstractEvent #event)
{
if (#event == null)
{
throw new ArgumentNullException("event");
}
ISession childSession = #event.Session.GetSession(EntityMode.Poco);
return childSession;
}
From the NHibernate documentation, this session should be a "child" session, that inherits all the attributes of it's parent - including the transaction.
Once we have created the entity, we save it to the session with:
childSession.Save(auditLogEntry);
All of this is called within a transaction and I would expect that the changes made to the childSession would flush once the transaction is committed. Unfortunately, nothing is happening and the changes are not flushing.
It should be noted that I can get this to work with a manual flush right after the save, but this won't work for us because the changes will no longer be batched (which will yield unacceptable performance).
At first I thought this behavior was limited to events, but I was able to abstract it out into a unit test to duplicate the behavior.
public void When_Saving_Audit_Log_Records_To_Child_Session_Flushes_When_Transaction_Committed()
{
ISession session = GetSession();
session.FlushMode = FlushMode.Commit;
ITransaction transaction = session.BeginTransaction();
ISession childSession = session.GetSession(EntityMode.Poco);
AuditLogEntry entry = CreateAuditLogEntry();
entry.AddAuditLogEntryDetail(CreateAuditLogEntryDetail());
entry.AddAuditLogEntryDetail(CreateAuditLogEntryDetail());
childSession.Save(entry);
transaction.Commit();
}
protected ISession GetSession()
{
return _sessionFactory.OpenSession();
}
I know that this is not your run of the mill NHibernate question, but if anyone has any experience or advice to share, I would love to hear it.
I am 2 seconds away from just writing the audit records out to a queue but I wanted to exhaust every possibility before giving up.
Thanks in advance,
Steve
The problem is from FlushMode.Commit: in this mode, NHibernate will only flush the session once, on committing transaction. So after it flush, it won't flush another time and any changes after the flushing will NOT be flushed.
To resolve this problem, you can either flush the session manually, or change to FlushMode.Auto. However, if you use Auto, beware of StackOverflowException with event listeners and/or interceptors, because with Auto, NHibernate will flush before querying, calling OnFlushDirty in as a result, so if you query something in OnFlushDirty, it will trigger another flushing, which then call OnFlushDirty again in a never ending loop. To prevent this situation, you must either temporarily change the FlushMode to Never, or implement a system to determine which changes has been processed to avoid processing the same change over and over.
We handle Auditing in the same way (with a GUID PK). When using Identity PK generator every call to Save issued an INSERT immediately, but when GUID is used the INSERTs are only executed during a Flush. We solved this years ago by patching the NHibernate source. In SessionImpl.cs in the Flush method (around line 1467) I added the following:
// Flush children when parent is flushed.
if (childSessionsByEntityMode != null) {
foreach (var childSession in childSessionsByEntityMode) {
childSession.Value.Flush();
}
}
I am trying to use NHibernate with legacy entities that are not mapped with NHibernate. On occasion this means that I need to manually flush NHibernate data to the database so that I don't receive foreign key exceptions when I try to connect the legacy entities with NHibernate-mapped entities.
A problem occurs when this takes place within a transaction that then needs to be rolled back. The data flushed from NHibernate does not rollback.
Is there anything I can do about this?
UPDATE
Still curious how to do this - I don't believe either of the answers given address the issue. I need to call Flush(). The question is, how do I rollback data that has been flushed?
check this: Force query execution without flush/commit
I seemed to have the same problem, i would flush and then i would rollback but some data would remain persisted in the database. However, there were some parts in my code that would call a commit, which cannot be rolled back. Consider the accepted answers' code snippet as the proper usage for transactions, flushes, rollbacks and commits and take into consideration that this pattern can be extended...
in a single unit of work (ie we consider a Request in a web application as a single unit of work and everything that happens in that request exists in a single transaction which onEndRequest is committed):
you call _sessionFactory.OpenSession(), _session.BeginTransaction(), _session.CommitTransaction() and _session.CloseSession() only once.
you can call _session.Flush() and _session.RollBackTransaction() as many times as you want, but Flush() is automatically called on Commit automatically. You may want to call a Flush when you need to make a query and ensure that the data fetched will not be stale.
Note that once a commit transaction is committed, all operations afterwards do not happen on that transaction. Instead NHibernate will create the necessary transaction under the hood (http://www.nhprof.com/Learn/Alerts/DoNotUseImplicitTransactions) in which point
you already have problems tracking consistency and possibly logical integrity
If you really must call commit in the middle of your unit of work it is strongly advised to create a new transaction at that point so you can manage it explicitly
What's even better is to try out Nested Transactions will allegedly allow partial commits; you can rollback the "root" transaction and all changes will be reverted. I haven't really tested this feature of .NET and SQL Server, although the nested transaction in the database itself leaves a lot to be desired and i don't know how exactly ADO.NET instruments this feature.
points 1 to 4 have been tested with all versions of NHibernate starting from 1.2.
For the sake of formatting I allow myself to update tolism7's answer here.
use using and forget about transaction.Dispose() - the transaction will automatically be Dispose'd of at the end of the using block.
throw - don't throw ex because it means throwing away your stacktrace (see this post where it states "When the .NET Framework executes this statement: throw ex; it throws away all the stack information above the current function.")
.
public void CommitChanges()
{
using (var transaction = Session.BeginTransaction()) // <-- open scope
try
{
// do something
transaction.Commit();
}
catch (HibernateException)
{
transaction.Rollback();
_session.Close();
_session.Dispose();
throw; // <-- this way the stacktrace stays intact!
}
}
A VB.NET version of this piece of code can be found here.
When using transactions with NHibernate try to avoid using the Session.Flush() and instead use the transaction.Commit() which it calls the session.flush() internally.
If during the Commit() an error occurs and the transaction needs to be rolled back this can be addressed like this.
public static void CommitChanges()
{
ITransaction transaction = Session.BeginTransaction();
try
{
transaction.Commit();
}
catch (HibernateException ex)
{
transaction.Rollback();
//close and dispose session here
throw ex;
}
finally
{
transaction.Dispose();
}
}
Now, if a manual call to flush() or a call to commit() goes through successfully there isn't a way to roll back the transaction using NHibernate mechanisms.
Especially when calling the transaction.Commit() command the AdoTransaction created by NHibernate is then disposed right after the Commit() finishes so you cannot access it in order to roll back.
The code sample above allows you to catch errors that happen during commit and then roll back the transaction that has started already.
Now instead of calling the transaction.Commit() in the sample above you call the session.Flush() in my tests no data are saved in the Database as the transaction is never commited.
I have no idea how your code looks like but if you are calling in a pattern, as the above the code sample shows, the transaction.commit() instead of the Session.Flush() it should give you a way to achieve what you want.
please help me resolve this problem:
There is an ambient MSMQ transaction. I'm trying to use new transaction for logging, but get next error while attempt to submit changes - "Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding." Here is code:
public static void SaveTransaction(InfoToLog info)
{
using (TransactionScope scope =
new TransactionScope(TransactionScopeOption.RequiresNew))
{
using (TransactionLogDataContext transactionDC =
new TransactionLogDataContext())
{
transactionDC.MyInfo.InsertOnSubmit(info);
transactionDC.SubmitChanges();
}
scope.Complete();
}
}
Please help me.
Thx.
You could consider increasing the timeout or eliminating it all together.
Something like:
using(TransactionLogDataContext transactionDC = new TransactionLogDataContext())
{
transactionDC.CommandTimeout = 0; // No timeout.
}
Be careful
You said:
thank you. but this solution makes new question - if transaction scope was changed why submit operation becomes so time consuming? Database and application are on the same machine
That is because you are creating new DataContext right there:
TransactionLogDataContext transactionDC = new TransactionLogDataContext())
With new data context ADO.NET opens up new connection (even if connection strings are the same, unless you do some clever connection pooling).
Within transaction context when you try to work with more than 1 connection instances (which you just did)
ADO.NET automatically promotes transaction to a distributed transaction and will try to enlist it into MSDTC. Enlisting very first transaction per connection into MSDTC will take time (for me it takes 30+ seconds), consecutive transactions will be fast, however (in my case 60ms). Take a look at this http://support.microsoft.com/Default.aspx?id=922430
What you can do is reuse transaction and connection string (if possible) when you create new DataContext.
TransactionLogDataContext tempDataContext =
new TransactionLogDataContext(ExistingDataContext.Transaction.Connection);
tempDataContext.Transaction = ExistingDataContext.Transaction;
Where ExistingDataContext is the one which started ambient transaction.
Or attemp to speed up your MS DTC.
Also do use SQL Profiler suggested by billb and look for SessionId between different commands (save and savelog in your case). If SessionId changes, you are in fact using 2 different connections and in that case will have to reuse transaction (if you don't want it to be promoted to MS DTC).