Which is better among Serializable and Externalizable?
I have experienced Externalizable is slower than Serializable.
Can somebody help me with this?
AFAIK, by default Ignite will not be using Serializable but will be marshalling with BinaryMarshaller. And that may be faster than Externalizable. Consider not having Externalizable unless it is explicitly needed.
Related
Redisson has several lock implementations ( RLock, RedissonMultiLock, RedissonRedLock), but what guarantees are provided in terms of safety and liveness for each of the lock types is not clear.
Referring to this - https://redis.io/topics/distlock I believe the RedLock implementation must be the most robust implementation, but nothing is mentioned regarding the lack of fault-tolerance wrt the other implementations.
Redisson lock objects have the same fault-tolerance property as Redis setup itself.
I am new to Infinispan and basically stumbled over it whilst looking for an isolated MVCC HashMap for Java.
I am concerned that Infinispan may be somewhat heavy for what I need or that there may be a more performant way to achieve what I need with Infinispan. I don't need clustering or distribution, I just need the embedded Infinispan inside a single JVM.
At the moment I need a Map implementation which has transactions and Repeatable Read semantics, I currently have the following initialization code:
final ConfigurationBuilder builder = new ConfigurationBuilder();
builder.jmxStatistics().available(false);
builder.invocationBatching().enable();
builder.versioning().scheme(VersioningScheme.SIMPLE);
builder.versioning().enable();
builder.locking().concurrencyLevel(Runtime.getRuntime().availableProcessors() * 2);
builder.locking().writeSkewCheck(true);
builder.transaction().locking().isolationLevel(IsolationLevel.REPEATABLE_READ);
builder.transaction().lockingMode(LockingMode.OPTIMISTIC);
builder.transaction().transactionMode(TransactionMode.TRANSACTIONAL);
final DefaultCacheManager cacheManager = new DefaultCacheManager(builder.build());
final Cache<String, String> cache = cacheManager.getCache();
final TransactionManager transactionManager = cache.getAdvancedCache().getTransactionManager();
I then use the cache from various threads like so:
transactionManager.begin();
cache.put(KEY, VALUE);
...
transactionManager.commit();
Is this the most effective/performant way I could achieve this, or should I consider a different class or are there some tuning options that I am not aware of?
Infinispan development is more focused on the clustered setup; local caches are rather a special case, and therefore their implementation may seem somewhat heavier.
You've missed builder.transaction().notifications(false) - that could slice another percent, and disables the ability to use transaction listeners. Also, you can experiment with budiler.transaction().useSynchronization(true), though with the dummy TM (which is used for invocation batching) it probably doesn't matter too much.
There's a cache mode optimized for local operations - simple cache but that does not support transactions. So, I'd say that this is pretty much all.
What is the need for Action classes to be serializable? When and how does it happen, if at all.
As far as I can tell, it doesn't need to be Serializable, and it was a mistake to make ActionSupport implement that interface.
Here is the best reasoning I have found on the subject (taken from here):
It's very common in web frameworks to use Serializable objects for a
couple or reasons, such as being able to preserve state across a
server restart and for shipping objects around in a cluster.
With that said, (IMHO) I believe it was a design mistake to have
ActionSupport implement Serializable. I don't believe that either of
the above really apply to Action objects since they are short-lived.
The choice of making Actions Serializable should have been left to
the developer and not "forced" by the framework.
This question might not be relevant anymore but I thought this might help.
From Sun developer network:
Object serialization is the process of saving an object's state to a sequence
of bytes, as well as the process of rebuilding those bytes into a live object
at some future time.
So why you might want to serialize your objects? That's when you need to persist their state
so you can use them later or in another JVM. The JVM might be on the same machine or over the network on another machine. I think that's the same case for ActionSupport class. If you extend ActionSupport you'll get the chance to serialize your action and send it over the network to be used in another JVM.
i don't know why it must be so. but action classes must extends ActionSupport. and according to http://struts.apache.org/2.0.6/struts2-core/apidocs/com/opensymphony/xwork2/ActionSupport.html , ActionSupport implements Serializable. so the answer to the when question, it happens all the time :p
I would like to ask users of the AOP framework Postsharp, what specifically are you using the framework for?
Also, I know it's use has a big negative impact on build times, but how about runtime performace? Is there much of a hit?
Thanks,
S
I use it to remove the property name smell from INotifyPropertyChanged methods, and it hasn't hugely affected runtime performance.
I use the compile time weaving to add extra functionality to some methods that have been decorated with a certain attribute.
Like here.
In short, it makes development faster, code more maintainable and easier to understand. There doesn't have to be a performance hit when you are willing to put in the effort.
We use it to inject our own aspects (persistent property accessors, construction notifiers, session & transaction activators, etc.) in DataObjects.Net.
If I have 10 database calls on my web page, and none of them require any transactions etc.
They are simply getting data from the database (reads), should I still use the unit of work class?
Is it because creating a new session per database call is too expensive?
With NHibernate, session factory creation is very expensive (so you'll want to cache the session factory once it's created, probably on the HttpApplication) but session creation is very cheap. In other words, if it keeps your code cleaner, multiple session creations is not necessarily a bad thing. I think the NH documentation says it best:
An ISessionFactory is an
expensive-to-create, threadsafe object
intended to be shared by all
application threads. An ISession is an
inexpensive, non-threadsafe object
that should be used once, for a single
business process, and then discarded.
So, using the UoW pattern is probably not more efficient due to the extra overhead, but it's a good practice and the overhead is probably not going to hurt you. Premature optimization and all that.
Yes, you should use a transaction. From Ayende's blog:
"NHibernate assume that all access to the database is done under a transaction, and strongly discourage any use of the session without a transaction."
For more details, here's a link to his blog posting:
http://ayende.com/Blog/archive/2008/12/28/nh-prof-alerts-use-of-implicit-transactions-is-discouraged.aspx