Welcome to the new Gigaspaces XAP forum. To recover your account, please follow these instructions.

Ask Your Question
0

exception after updating from 7.1.0 to 7.1.2

Hi,
We recently made an update of GigaSpaces version without touching the code in classes related to the following exception we get now:

java.lang.IllegalArgumentException: Using EXCLUSIVEREADLOCK modifier without a transaction is illegal.
at com.gigaspaces.internal.client.spaceproxy.actions.AbstractSpaceProxyActionManager.readById(AbstractSpaceProxyActionManager.java:174)
        at com.gigaspaces.internal.client.spaceproxy.AbstractSpaceProxy.readById(AbstractSpaceProxy.java:198)
        at com.gigaspaces.internal.client.dcache.AbstractSpaceCache.readById(AbstractSpaceCache.java:620)
at com.mypackage.MyClass.myMethod(...)

We get this at the line:
cachedSpace.readById(AClass.class.getName(), value, value, null, JavaSpace.NOWAIT, TransactionDefinition.ISOLATIONDEFAULT, false, null);
where:
cachedSpace = (ISpaceProxy) new LocalCacheSpaceConfigurer(gigaSpace.getClustered().getSpace()).updateMode(LocalCacheSpaceConfigurer.UpdateMode.PULL).localCache();
where:
@GigaSpaceContext(name = "gigaSpace")
public static GigaSpace gigaSpace;
and
<os-core:space id="space" url="/./appSpace?NOWriteLease=true">
        <os-core:properties>
            <props>
                <prop key="space-config.leasemanager.expirationtime_interval">1000</prop>
                <prop key="space-config.engine.cache_policy">1</prop>
            </props>
        </os-core:properties>
</os-core:space>
<os-core:local-tx-manager id="transactionManager" space="space">
        <os-core:renew pool-size="2" duration="1000" round-trip-time="500" />
</os-core:local-tx-manager>
<os-core:giga-space id="gigaSpace" space="space" tx-manager="transactionManager"/>

Is there something we are doing wrong? I didn't intend to use a transaction with the cached space, just the optimistic locking.
The most strange is we didn't see this before updating to 7.1.2

Thanks,
Lucian

This thread was imported from the previous forum.
For your reference, the original is available here

asked 2010-12-21 03:49:12 -0600

lukeh gravatar image

updated 2013-08-08 09:52:00 -0600

jaissefsfex gravatar image
edit retag flag offensive close merge delete

1 Answer

Sort by » oldest newest most voted
0

Lucian,
Starting with 7.1.2 Gigaspaces throws an exception as a protection mechanism when performing exclusive read without a transaction.
You must use a transaction when using exclusive read lock.

Are you sure you are not running in EXCLUSIVEREADLOCK mode?
Shay

answered 2010-12-21 07:31:00 -0600

shay hassidim gravatar image
edit flag offensive delete link more

Comments

Hi Shay, I don't remember setting EXCLUSIVE_READ_LOCK anywhere. I double checked running a search for "EXCLUSIVE_READ_LOCK" in the project but couldn't I find any. Unless that is somehow the default setting how could I have done that? Anyway, using TransactionDefinition.ISOLATION_READ_COMMITTED with null transaction in that readById seems to solve the problem. Do you see any problem with this approach? Can I consider that a permanent fix? Also did I understood correctly the optimistic locking? That should work with null transaction, right? Thanks, Lucian

lukeh gravatar imagelukeh ( 2010-12-21 07:48:05 -0600 )edit

Yes - optimistic locking should use a null transaction. See details here: http://www.gigaspaces.com/wiki/displa...

Pessimistic Locking must use a transaction. See: http://www.gigaspaces.com/wiki/displa...

Since I don't know your system I can't tell if optimistic locking or pessimistic locking is the right approach for you. The rule is simple: if you read and always update, pessimistic locking would be better. if you read and might update the object, optimistic locking would be better.

Shay

shay hassidim gravatar imageshay hassidim ( 2010-12-21 07:57:20 -0600 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2010-12-21 03:49:12 -0600

Seen: 60 times

Last updated: Dec 21 '10