QSAC persistence

1 view
Skip to first unread message

Norman Gray

unread,
Jan 11, 2009, 1:32:09 PM1/11/09
to skua-d...@googlegroups.com

Folks,

Happy New Year!

Sorry for being largely off-air at the end of last year and this last
week.

I've finally managed, I believe, to get persistence working in a more
intuitive way within QSAC. Now, SACs are created as persistent by
default, and are resurrected when a SAC is restarted. Let me know if
the result isn't as usable as I think it is.

We should get back our iteration rhythm -- we were doing quite well
for a while last term.

See you,

Norman


--
Norman Gray : http://nxg.me.uk
Dept Physics and Astronomy, University of Leicester

Kona Andrews

unread,
Jan 12, 2009, 6:30:16 AM1/12/09
to skua-d...@googlegroups.com
Hi Norman,

>
> I've finally managed, I believe, to get persistence working in a more
> intuitive way within QSAC. Now, SACs are created as persistent by
> default, and are resurrected when a SAC is restarted. Let me know if
> the result isn't as usable as I think it is.

I presume this still requires Java 1.6? If so I'll move the test tomcat
onto 1.6 and see if it still works :-0

> We should get back our iteration rhythm -- we were doing quite well
> for a while last term.

Yes, I've been a bit sluggish of late too, sorry.

I went round and round in circles on the subject of a more
object-oriented API supporting Jena, in particular the issue of where
state was being maintained (at the SAC vs at the client) and how
consistency could be assured. In the end I decided that I was trying
to solve the wrong problem, and that trying to be more "Java-y" in
wrapping a simple restful interface with a stateful set of Java classes
was causing more problems than it solved.

I'm now simply (or should I say "simply", being Jena) bolting in some
methods to return RDF metadata/data in the form of a Jena Resource.
At some point, if need be, we can change those interfaces to use a more
abstract "SkuaResource", of which a "JenaResource" could be an instance -
but I thought it better at this stage to make basic Jena resources
available directly in order to discover which Resource methods are
actually needed/useful.

Cheers,
Kona
--
Kona Andrews k...@roe.ac.uk
AstroGrid Project http://www.astrogrid.org
IfA, Royal Observatory, Blackford Hill, Edinburgh EH9 3HJ

Norman Gray

unread,
Jan 12, 2009, 7:00:33 AM1/12/09
to skua-d...@googlegroups.com

Kona, hello.

On 2009 Jan 12, at 11:30, Kona Andrews wrote:

>> I've finally managed, I believe, to get persistence working in a more
>> intuitive way within QSAC. Now, SACs are created as persistent by
>> default, and are resurrected when a SAC is restarted. Let me know if
>> the result isn't as usable as I think it is.
>
> I presume this still requires Java 1.6? If so I'll move the test
> tomcat
> onto 1.6 and see if it still works :-0

Ah yes, it does (because the persistence framework TDB does). The
standalone QSAC release works without Tomcat, though, so that's an
alternative.

>> I went round and round in circles on the subject of a more
> object-oriented API supporting Jena, in particular the issue of where
> state was being maintained (at the SAC vs at the client) and how
> consistency could be assured. In the end I decided that I was trying
> to solve the wrong problem, and that trying to be more "Java-y" in
> wrapping a simple restful interface with a stateful set of Java
> classes
> was causing more problems than it solved.

Yes -- I think the problem is that the state _is_ being maintained
entirely at the server end, which means that an O-O client kit can
easily end up feeling weird. A slightly tricky design problem, but in
the end probably a matter of taste.

All the best,

Reply all
Reply to author
Forward
0 new messages