Re: how to put output of sparql query in jtable
In the past when displaying the results of a SPARQL query in a browser I have used javascript and taken the SPARQL result from Fuseki in a JSON format. This makes it rather trivial do do. I am unfamiliar with the JTable properties, but if it can parse and display JSON or XML you might use the ResultSetFormatter to produce a string that JTable then parses. Or you might look at the ResultSetFormatter code to see how to produce a formatter that would write into the JTable. ref: https://jena.apache.org/documentation/javadoc/arq/index.html Claude On Fri, May 2, 2014 at 11:38 PM, ameni ameni ameni.abdeljao...@gmail.comwrote: Hello, I need to know the instructions that allow me to put the result/output of a SPARQL query in a JTable in netbeans. Thanks for help -- I like: Like Like - The likeliest place on the webhttp://like-like.xenei.com LinkedIn: http://www.linkedin.com/in/claudewarren
Re: SPARQL update on TDB API frozen at transaction begin
On 05/02/14 21:19, Jean-Marc Vanel wrote:
In fact, isInTransaction() returns false
( because ThreadLocal returns setInitialValue() ) ,
so there must be something broken in the TDB dataset .
isInTransaction returning true means that the current thread is in a
transaction, not that there is some other somewhere else in a
transaction on the same dataset.
TDB is single writer AND multiple reader. writers get queued on the
lock you are seeing so my best guess is that another thread has started
a write transaction and not committed or aborted it (hence the resources
style suggestion in the API documentation using finally)
Andy
2014-05-02 21:26 GMT+02:00 Andy Seaborne a...@apache.org:
On 02/05/14 18:48, Jean-Marc Vanel wrote:
Yes , it can be the case that another thread is accessing the dataset.
From what you write, and the doc.:
https://jena.apache.org/documentation/tdb/tdb_transactions.html
I understand that the kind of access that can be the cause of this
transaction not opening is
a write transaction not closed in another thread.
Yes - it's waiting on the writer transaction lock.
I have a suspect in my app code,
but is there a way to know at runtime the status of a dataset regarding
transactions ?
with more detail like the thread than :
public boolean isInTransaction() ;
There isn't another way but isInTransaction() is backed by a ThreadLocal
so it does tell you the state from the thread viewpoint.
Andy
2014-05-02 18:20 GMT+02:00 Andy Seaborne a...@apache.org:
Hi,
Do you have a complete, minimal example?
I built a test from the details below and it works so maybe it something
related but not shown here.
The other thing to consider is whether any other thread is accessing the
dataset.
Andy
On 02/05/14 14:15, Jean-Marc Vanel wrote:
Hi
I'm trying to delete a whole named graph.
The code:
try {
Dataset dataset = TDBFactory.createDataset(
directory.getAbsolutePath());
UpdateProcessor qexec = UpdateExecutionFactory.create(request,
GraphStoreFactory.create( dataset ) );
dataset.begin( ReadWrite.WRITE ); // frozen here !!
qexec.execute();
dataset.commit();
}
The SPARQL :
WITH file:/home/jmv/ontologies/unspsc84-title.rdfs.n3
DELETE { ?subject ?property ?value }
WHERE { ?subject ?property ?value }
The stack when suspending in debugger:
Daemon Thread [SwingWorker-pool-4-thread-1] (Suspended)
Unsafe.park(boolean, long) line: not available [native method]
LockSupport.park(Object) line: 186
Semaphore$FairSync(AbstractQueuedSynchronizer).parkAndCheckInterrupt()
line: 834
Semaphore$FairSync(AbstractQueuedSynchronizer).
doAcquireSharedInterruptibly(int)
line: 994
Semaphore$FairSync(AbstractQueuedSynchronizer).
acquireSharedInterruptibly(int)
line: 1303
Semaphore.acquire() line: 317
TransactionManager.begin(ReadWrite, String) line: 306
TransactionManager.begin(ReadWrite) line: 287
StoreConnection.begin(ReadWrite) line: 103
DatasetGraphTransaction._begin(ReadWrite) line: 155
DatasetGraphTransaction(DatasetGraphTrackActive).begin(ReadWrite) line:
42
DatasetImpl.begin(ReadWrite) line: 125
Jena:
dependency
groupIdorg.apache.jena/groupId
artifactIdapache-jena-libs/artifactIdversion2.11.1/
version
typepom/type
/dependency
The system:
% uname -a
Linux oem-laptop 3.11.0-20-generic #34-Ubuntu SMP Tue Apr 1 20:40:25 UTC
2014 x86_64 x86_64 x86_64 GNU/Linux
% java -version
java version 1.7.0_51
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)
For more details, I'll be on IRC #jena .
Re: SPARQL update on TDB API frozen at transaction begin
This might help:
// Setup:
Dataset dataset =
DatasetGraphTransaction dsgt =
(DatasetGraphTransaction) (dataset.asDatasetGraph()) ;
Location loc = dsgt.getLocation() ;
StoreConnection sConn = StoreConnection.make(loc) ;
// then anywhere:
System.out.println(sConn.getTransMgrState()) ;
will print some internal counters. It is a snapshot of the state at the
point of the call, not a live connection.
e.g.
Active (R=0 W=0) : Finished (R=0, WC=1, WA=0) Queue 1
Active - current transactions for this location.
WC - writer commited
WA = writer aborted
This does not work on all TDB datasets (particularly the anonymous
in-memory ones which you are not using).
Andy
PS I've just added a method to DatasetGraphTransaction to get this state
more conveniently which will work for all datasets.
On 05/03/14 09:54, Andy Seaborne wrote:
On 05/02/14 21:19, Jean-Marc Vanel wrote:
In fact, isInTransaction() returns false
( because ThreadLocal returns setInitialValue() ) ,
so there must be something broken in the TDB dataset .
isInTransaction returning true means that the current thread is in a
transaction, not that there is some other somewhere else in a
transaction on the same dataset.
TDB is single writer AND multiple reader. writers get queued on the
lock you are seeing so my best guess is that another thread has started
a write transaction and not committed or aborted it (hence the resources
style suggestion in the API documentation using finally)
Andy
2014-05-02 21:26 GMT+02:00 Andy Seaborne a...@apache.org:
On 02/05/14 18:48, Jean-Marc Vanel wrote:
Yes , it can be the case that another thread is accessing the dataset.
From what you write, and the doc.:
https://jena.apache.org/documentation/tdb/tdb_transactions.html
I understand that the kind of access that can be the cause of this
transaction not opening is
a write transaction not closed in another thread.
Yes - it's waiting on the writer transaction lock.
I have a suspect in my app code,
but is there a way to know at runtime the status of a dataset regarding
transactions ?
with more detail like the thread than :
public boolean isInTransaction() ;
There isn't another way but isInTransaction() is backed by a ThreadLocal
so it does tell you the state from the thread viewpoint.
Andy
2014-05-02 18:20 GMT+02:00 Andy Seaborne a...@apache.org:
Hi,
Do you have a complete, minimal example?
I built a test from the details below and it works so maybe it
something
related but not shown here.
The other thing to consider is whether any other thread is
accessing the
dataset.
Andy
On 02/05/14 14:15, Jean-Marc Vanel wrote:
Hi
I'm trying to delete a whole named graph.
The code:
try {
Dataset dataset = TDBFactory.createDataset(
directory.getAbsolutePath());
UpdateProcessor qexec = UpdateExecutionFactory.create(request,
GraphStoreFactory.create( dataset ) );
dataset.begin( ReadWrite.WRITE ); // frozen here !!
qexec.execute();
dataset.commit();
}
The SPARQL :
WITH file:/home/jmv/ontologies/unspsc84-title.rdfs.n3
DELETE { ?subject ?property ?value }
WHERE { ?subject ?property ?value }
The stack when suspending in debugger:
Daemon Thread [SwingWorker-pool-4-thread-1] (Suspended)
Unsafe.park(boolean, long) line: not available [native method]
LockSupport.park(Object) line: 186
Semaphore$FairSync(AbstractQueuedSynchronizer).parkAndCheckInterrupt()
line: 834
Semaphore$FairSync(AbstractQueuedSynchronizer).
doAcquireSharedInterruptibly(int)
line: 994
Semaphore$FairSync(AbstractQueuedSynchronizer).
acquireSharedInterruptibly(int)
line: 1303
Semaphore.acquire() line: 317
TransactionManager.begin(ReadWrite, String) line: 306
TransactionManager.begin(ReadWrite) line: 287
StoreConnection.begin(ReadWrite) line: 103
DatasetGraphTransaction._begin(ReadWrite) line: 155
DatasetGraphTransaction(DatasetGraphTrackActive).begin(ReadWrite)
line:
42
DatasetImpl.begin(ReadWrite) line: 125
Jena:
dependency
groupIdorg.apache.jena/groupId
artifactIdapache-jena-libs/artifactIdversion2.11.1/
version
typepom/type
/dependency
The system:
% uname -a
Linux oem-laptop 3.11.0-20-generic #34-Ubuntu SMP Tue Apr 1
20:40:25 UTC
2014 x86_64 x86_64 x86_64 GNU/Linux
% java -version
java version 1.7.0_51
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)
For more details, I'll be on IRC #jena .
Re: Getting classes from an ontology
On 05/03/14 00:02, Cindy A McMullen wrote: Unfortunately, we're using an older version of Jena (2.7.2) for compatibility with the Oracle Jena adapter. I see more recent versions have these methods on OntModel: listClasses() listDatatypeProperties() and so on. How can I do the equivalent using Jena 2.7.2? Those exist in my copies of jena 2.7.2 (and earlier as well). (Your other choice is to look at the source code for a later version and see what the code does then provide the same functionality). Andy Thanks - -- Cindy
Re: SPARQL update on TDB API frozen at transaction begin
On 05/03/14 17:31, Jean-Marc Vanel wrote:
Thanks for the advice ;
currently I suspect that *several* threads start a transaction, via a same
Dataset object ;
which tdb_transactions.html explicitely discourages.
Where? That's normal practice.
It does talk about sharing one transaction bewteen threads. Technically
possible but only diving into implementation classes.
You can have two transactional views (two datasets, same location) on
one thread as well but that can deadlock.
Your code snippet is not running inside another transaction is it?
This will deadlock:
dataset1.begin(ReadWrite.WRITE);
dataset2.begin(ReadWrite.WRITE);
dataset2.commit();
dataset2.end();
dataset1.commit();
dataset1.end();
because dataset1 takes the lock, and effectively, is waiting for
dataset2, but it can't proceed because its waiting on dataset1. Opps.
Nested transactions are not provided.
Can you confirm that it's OK that *several* threads start a transaction,
via a same directory TBD location but distinct Dataset objects ?
Yes - but better to have one Dataset for one location.
It's unnecessary to have multiple datasets for one location; you don't
gain anything.
Is it costly to build a Dataset object via TDBFactory.createDataset() ?
No -- No disk involved, no large scale data copying at create time.
But better to share the Dataset object. Note the mentioned use of
ThreadLocal variables internally so each thread has it's own
transactional scope per dataset object.
If I understand the PS , you have added in Subversion method getT
ransMgrState to DatasetGraphTransaction ?
Yes.
My code example showed how to get it with released TDB.
Andy
2014-05-03 12:15 GMT+02:00 Andy Seaborne a...@apache.org:
This might help:
// Setup:
Dataset dataset =
DatasetGraphTransaction dsgt =
(DatasetGraphTransaction) (dataset.asDatasetGraph()) ;
Location loc = dsgt.getLocation() ;
StoreConnection sConn = StoreConnection.make(loc) ;
// then anywhere:
System.out.println(sConn.getTransMgrState()) ;
will print some internal counters. It is a snapshot of the state at the
point of the call, not a live connection.
e.g.
Active (R=0 W=0) : Finished (R=0, WC=1, WA=0) Queue 1
Active - current transactions for this location.
WC - writer commited
WA = writer aborted
This does not work on all TDB datasets (particularly the anonymous
in-memory ones which you are not using).
Andy
PS I've just added a method to DatasetGraphTransaction to get this state
more conveniently which will work for all datasets.
On 05/03/14 09:54, Andy Seaborne wrote:
On 05/02/14 21:19, Jean-Marc Vanel wrote:
In fact, isInTransaction() returns false
( because ThreadLocal returns setInitialValue() ) ,
so there must be something broken in the TDB dataset .
isInTransaction returning true means that the current thread is in a
transaction, not that there is some other somewhere else in a
transaction on the same dataset.
TDB is single writer AND multiple reader. writers get queued on the
lock you are seeing so my best guess is that another thread has started
a write transaction and not committed or aborted it (hence the resources
style suggestion in the API documentation using finally)
Andy
2014-05-02 21:26 GMT+02:00 Andy Seaborne a...@apache.org:
On 02/05/14 18:48, Jean-Marc Vanel wrote:
Yes , it can be the case that another thread is accessing the dataset.
From what you write, and the doc.:
https://jena.apache.org/documentation/tdb/tdb_transactions.html
I understand that the kind of access that can be the cause of this
transaction not opening is
a write transaction not closed in another thread.
Yes - it's waiting on the writer transaction lock.
I have a suspect in my app code,
but is there a way to know at runtime the status of a dataset regarding
transactions ?
with more detail like the thread than :
public boolean isInTransaction() ;
There isn't another way but isInTransaction() is backed by a ThreadLocal
so it does tell you the state from the thread viewpoint.
Andy
2014-05-02 18:20 GMT+02:00 Andy Seaborne a...@apache.org:
Hi,
Do you have a complete, minimal example?
I built a test from the details below and it works so maybe it
something
related but not shown here.
The other thing to consider is whether any other thread is
accessing the
dataset.
Andy
On 02/05/14 14:15, Jean-Marc Vanel wrote:
Hi
I'm trying to delete a whole named graph.
The code:
try {
Dataset dataset = TDBFactory.createDataset(
directory.getAbsolutePath());
UpdateProcessor qexec = UpdateExecutionFactory.create(request,
GraphStoreFactory.create( dataset ) );
dataset.begin( ReadWrite.WRITE ); // frozen here !!
qexec.execute();
dataset.commit();
}
The SPARQL :
WITH file:/home/jmv/ontologies/unspsc84-title.rdfs.n3
DELETE { ?subject ?property ?value }
WHERE {
