new proposal for tx timeout handling using transaction DISASSOCIATING event notification...
by Scott Marlow
With a proposed TM level listener, we will have an SPI for notification
of when application threads associated with a JTA transaction, become
disassociated with the transaction (tm.commit/rollback/suspend time).
Having this knowledge in a synchronization callback, can determine
whether the persistence context should be cleared directly from the
Synchronization.afterCompletion(int) call or should be deferred until
the transaction is disassociated from the JTA transaction.
This idea is based on a TM level listener approach that Tom Jenkinson
[1] suggested. Mike Musgrove has a "proof of concept" implementation of
the suggested changes [2]. I did some testing with [3] to see if the
improvement helps with clearing entities that might still be in the
persistence context after a background tx timeout.
I'm wondering if in the Hibernate ORM
Synchronization.afterCompletion(int status) implementation, in case of
tx rollback, if we could defer the clearing of the Hibernate session to
be handled by the JtaPlatform. This could be setup at
EntityManager.joinTransaction() time (if a new property like
"hibernate.transaction.defer_clear_session" is true). Perhaps via a
JtaPlatform.joinTransaction(EntityManager) registration call?
Thoughts?
Scott
[1] https://developer.jboss.org/thread/252572?start=45&tstart=0
[2]
https://github.com/mmusgrov/jboss-transaction-spi/blob/threadDisassociati...
[3]
https://github.com/scottmarlow/wildfly/tree/transactiontimeout_clientut_n...
10 years, 12 months
JmxService
by Steve Ebersole
Anyone using the JmxService?
11 years
[OGM] Thoughts for the Infinispan / Hot Rod dialect
by Sanne Grinovero
Hi all,
with Infinispan in embedded mode we used AtomicMaps and
FineGrainedAtomicMaps as an alternative way to map attributes and
relations.
In particular the relations are interesting because in SQL world one
would run a query on junction tables, and on Infinispan embedded
queries would only be an option on Hibernate Search / Infinispan Query
annotated attributes, and also the AtomicMaps allow us to only load
the section of relevant data (like on a RDBMs).
The difference between the two kinds of AtomicMaps is in the locking
level, each similar to the same kind of locking we'd normally have.
On Hot Rod, AtomicMaps are not available so we opened (a long time
ago) a feature request to implement them for Hot Rod - at least Java
clients. Still, we don't have transactions in this case either so the
locking benefits are also unavailable.
I think that in the case of Hot Rod clients we should not use
AtomicMaps, but rather resort to a protobuf schema generation, and
essentially use the more traditional "query on jointables" approach.
Hot Rod nowadays supports queries, and they can be indexed or non
indexed so we could enable indexing on the ad-hoc tables we build for
relations mapping, have the user "opt in" for additional indexes, and
still allow some level of querying for the fields which have not been
indexed; of course w/o join operations.
We can generate an appropriate schema and upload it to Hot Rod
automatically; that sounds like a great usability improvement for all
Java clients dealing with Infinispan/remote, as its schema ads quite
some stuff to the learning curve.
Still, this automatic generation is a new and challenging field; some notes:
- protobuf schemas are generational -> more effective if you can
generate the new one based on the existing one
- there's a Java encoder by Adrian here:
https://github.com/infinispan/protostream
- Typically one would need to assign a stable sequence id to each field
- previous points will likely want us to dump the output resource
somewhere, maybe even persist on Infinispan?
On a very different topic, we also typically require from a
GridDialect implementor to provide sequence generation capability. I
don't see a solution for that over Hot Rod, it doesn't currently have
any safe incremental id, but when I asked today I was told that
Infinispan 8 might have it; Tristan pointed out you can upload a
script and have it run on the server, which in turn has access to the
transactions API so this should be possible but doesn't look too easy.
Finally, we'll need using the distributed remote iterator for
GridDialect#forEachTuple.
So my conclusion is that to support Hot Rod we'd be better off to make
a completely different GridDialect than the one for Infinispan
embedded, as I can hardly see some shared code.
Would you agree on try basing the approach on a brand new dialect and
on protobuf schema generation? In terms of features, we can implement
them all except:
- transactions & locks
- join queries
Thanks,
Sanne
11 years
Next 5.0 release
by Steve Ebersole
I am feeling like so many changes to SPIs have piled up on master since CR2
that another CR is warranted. Everyone ok with doing a CR3?
11 years
MariaDB on CI
by Steve Ebersole
[18:45] <sebersole> whoa..
[18:45] <sebersole> sannegrinovero: we definitely need this for mariadb on
ci...
[18:46] <sebersole> sync_binlog=0 innodb_flush_log_at_trx_commit=0
innodb_doublewrite=0
[18:46] <sebersole> tests were much faster
These were suggested to me on the #mariadb list. I added them to my local
/etc/my.cnf file and the tests were significantly faster.
11 years
[OGM] GridDialect facets
by Emmanuel Bernard
I have been adding a facet to GridDialect and found it surprisingly hard:
* I was not sure which non datastore dialects was supposed to implement the facet nor really how to find these non datastore dialects. I am talking about GridDialectLogger, ForwardingGridDialect and InvokedOperationsLoggingDialect. I am sure there are more of these non datastore dialects but I haven’t found them.
* Adding one method, to a facet means having to go to a lot of places to write all these logging and delegating logics. Changing a method sig a least gives you the help of the compiler but not for adding them.
* Find how consumers of the facet are supposed to use them was not obvious to me. It seems a given consumer stores all the possible facets as class field and do a null check before using them.
* when I finally ran my tests everything exploded because each facet must have a MyFacetInitiator
* when I added the initiator, it still blew up at my face because each Initiator must be listed in the OgmIntegrator
* I’m also concerned about facet discoverability, I don’t think it’s trivial for a dialect implementor to get the list of facets easily, which will tend to bring minimal dialects without the advanced features.
I wonder if and / or how we should improve that state of affairs.
Emmanuel
11 years
in.relation.to local building, Fedora 22
by Steve Ebersole
[sebersole@t540 in.relation.to] $ rake check
rake aborted!
Don't know how to build task 'check'
^^ expected? `rake setup` finished successfully. This next step failed
for me.
11 years
