OK solved.
I found the answer here:
http://www.jboss.org/index.html?module=bbop=viewtopicp=4211379#4211379
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4230747#4230747
Reply to the post :
Have you checked the insert SQL also?
Conceptual Understanding
Cache Loader maintains evicted data from memory in a persistent store (DB, file
system).
Does caching solutions offer synchronization between actual source of data
(mostly DB) and in memory data (cache)? E.g. I am caching data from
Have you checked the insert SQL also?
Conceptual Understanding
Cache Loader maintains evicted data from memory in a persistent store (DB, file
system).
| Does caching solutions offer synchronization between actual source of data
(mostly DB) and in memory data (cache)? E.g. I am caching data
The cache loader will modify the data in the store (database in your scenario)
when in memory data gets changed. What it won't do is update in-memry data
whenever data gets modified in the database. The way the data from DB is
updated when an in memory change is made is influenced by the
atifoxon wrote : Have you checked the insert SQL also?
I thought you said it was just the create table DDL that was broken. Have you
tried it with my workaround? Could just be that your table structure was
broken and hence the other SQL not working.
View the original post :
manik.surt...@jboss.com wrote : atifoxon wrote : Have you checked the
insert SQL also?
|
| I thought you said it was just the create table DDL that was broken. Have
you tried it with my workaround? Could just be that your table structure was
broken and hence the other SQL not working.
After installing Informix (whew!!) and giving it a go, I see your problem with
the DDL. I have fixed this in trunk and have included info on a workaround on
the JIRA. Please let me know if you see any other issues.
View the original post :
we haven't tested this with informix.
Does the insert statement fail when you attempt to type in directly into an
informix console? What do the existing tables look like?
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4209019#4209019
Reply to the post :
yes both statements (create table and insert) generates a syntax error when
tried through a console
tables are as
store table
| CREATE
| TABLE jbosscache
| (
| fqn VARCHAR(255) NOT NULL,
| node BLOB,
| parent VARCHAR(255),
| PRIMARY
I've raised a bug. https://jira.jboss.org/jira/browse/JBCACHE-1477
1) Could you pls paste the error message you get from the DB?
2) Also, is it only the insert SQL that fails?
3) Why do you say the create table DDL is incorrect? Does this fail when run
on the DB directly?
View the original
than you for your follow up
1) I am getting following error repeatedly whenever the evicted node is about
to be persisted to store (DB)
Feb 12, 2009 10:47:49 AM org.jboss.cache.loader.AdjListJDBCCacheLoader
insertNode
| SEVERE: Failed to insert node :A syntax error has occurred.
|
2) I
Looks like you had a communication timeout. This could be caused by any number
of things, including a slow network, etc.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4201016#4201016
Reply to the post :
we are using JBOSS 4.2.1 GA
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4200835#4200835
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4200835
___
jboss-user mailing list
Are you using different versions of JBC on the same network? Some of those
magic numbers don't exist in JBC. :-)
Are you trying commit a transaction with a lot of modifications, perhaps?
Wonder if this is a case of JBCACHE-1211.
View the original post :
Any one has a solution for this problem of mine ?
Is it JGroup problem which i should ask there or is it the new version of jboss
cache exception.
Any one on jboss cache team ?
Regards,
Dor
dorbd wrote : I am getting the following exception:
|
| 08:18:25,820 ERROR [CacheMarshaller210]
Hi
Thanks for spotting this, this is quite a nasty problem. You're correct in that
it ought to be defensively copied while we still have locks on the node, to
prevent this issue.
I'm going to create a JIRA and unit test for this, but for the time being if
you want a workaround you could try
FYI - JBCACHE-1337
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4148078#4148078
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4148078
___
jboss-user mailing list
Cheers. The JIRA issue is currently due for 2.2.0, is this correct or do you
think it might be included in 2.1.1? If the fix is likely to be included in
2.1.1 then we wont bother with implementing a workaround but rather wait for
2.1.1 =)
View the original post :
Sadly, 2.1.1 is in QA right now and very close to being released. If there was
no workaround, I would have stopped the presses for this, but since there is
a workaround I'd prefer not to do that.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4148098#4148098
The returned map from the node seems to be an instance of
java.util.Collections$UnmodifiableMap. The javadoc for the UnmodifiableMap
specifies:
anonymous wrote : unmodifiableMap
|
| public static K,V MapK,V unmodifiableMap(Map? extends K,? extends V m)
|
| Returns an unmodifiable
20 matches
Mail list logo
