Allright, cool.
2008/5/11 Philip Jägenstedt <[EMAIL PROTECTED]>:
> Sure. Unfortunately there are a lot of dependencies, but if you give
> me some time I could try to remove as much as possible and then send a
> copy.
>
> Philip
>
> On 5/11/08, Mattias Persson <[EMAIL PROTECTED]> wrote:
>> Allright
Sure. Unfortunately there are a lot of dependencies, but if you give
me some time I could try to remove as much as possible and then send a
copy.
Philip
On 5/11/08, Mattias Persson <[EMAIL PROTECTED]> wrote:
> Allright, gotcha. I could try to reproduce the problem you had using
> your code and m
Allright, gotcha. I could try to reproduce the problem you had using
your code and maybe find bugs related to it!
2008/5/11 Philip Jägenstedt <[EMAIL PROTECTED]>:
> No, that part of the code isn't the problem. It's there because I left
> it when moving the transaction outside the loop to reproduce
No, that part of the code isn't the problem. It's there because I left
it when moving the transaction outside the loop to reproduce the
error, it wasn't even there when the problem first occured.
On 5/11/08, Mattias Persson <[EMAIL PROTECTED]> wrote:
> Also with some irrelevant parts taken out:
>
Also with some irrelevant parts taken out:
for ( UUID id : artistIds ) {
...
try {
artist.updateWikipediaBlurb();
} catch (WikipediaException e) {
// FIXME: log this error!
tx.failure();
continue;
}
...
}
2008/5/11 Philip Jägenstedt <
With some irrelevant parts taken out:
Transaction tx = Transaction.begin();
try {
for (UUID id : artistIds) {
MushArtist artist = maf.getArtistById(id);
if (artist == null) {
// replicate data from MusicBrainz WebService
try {
Query q = new Que
2008/5/11 Philip Jägenstedt <[EMAIL PROTECTED]>:
> On 5/11/08, Mattias Persson <[EMAIL PROTECTED]> wrote:
>> Allright, I'm pretty sure that it's all about the usage of
>> tx.failure() (which is very seldom needed btw). In the first code
>> snippet you call tx.failure() inside the for-loop and con
On 5/11/08, Mattias Persson <[EMAIL PROTECTED]> wrote:
> Allright, I'm pretty sure that it's all about the usage of
> tx.failure() (which is very seldom needed btw). In the first code
> snippet you call tx.failure() inside the for-loop and continues.
No, I throw an Exception. updateWikipediaBlur
Allright, I'm pretty sure that it's all about the usage of
tx.failure() (which is very seldom needed btw). In the first code
snippet you call tx.failure() inside the for-loop and continues. That
seems a little odd to me since tx.failure() ensures that the
transaction can't be committed, allthough I
On 5/11/08, Mattias Persson <[EMAIL PROTECTED]> wrote:
> Hmm allright, great that it's working though. Also it would be nice to
> know which structural changes you made to your code to make it work.
What this code does is to take a bunch of ids and for each of them (a)
replicate the musicbrainz e
2008/5/11 Philip Jägenstedt <[EMAIL PROTECTED]>:
> I'm using NeoIndexService. I've tried very hard to reproduce the bug
> outside of tomcat but have failed to do so. Rearranging my code a bit
> and handling the exceptions better seems to fix this problem, by I
> don't know if it's by accident or no
I'm using NeoIndexService. I've tried very hard to reproduce the bug
outside of tomcat but have failed to do so. Rearranging my code a bit
and handling the exceptions better seems to fix this problem, by I
don't know if it's by accident or not.
If I write I create nodes, write properties and index
I guess having each request wrapped in one transaction sounds sane and
to answer your previous question the indices (changes to your
IndexService) aren't really written until you call tx.finish(). So
that's either a bug in the IndexService (btw which one do you use,
LuceneIndexService or NeoIndexSe
On 5/10/08, Johan Svensson <[EMAIL PROTECTED]> wrote:
> If tx.finish() is never called the transaction will never be committed
> or rolled back (holding locks/memory).
I only have a single transaction wrapping everything I do for the
entire request. Not nice maybe, I'm trying to work out some be
On Sat, May 10, 2008 at 9:04 PM, Philip Jägenstedt <[EMAIL PROTECTED]> wrote:
> Perhaps my question could also be phrased as:
>
> What happens if tx.finish() is never called? I don't know what tomcat
> does when it times out, but I expect it might kill the running servlet
> quite "brutally".
>
If
Perhaps my question could also be phrased as:
What happens if tx.finish() is never called? I don't know what tomcat
does when it times out, but I expect it might kill the running servlet
quite "brutally".
Philip
On 5/10/08, Philip Jägenstedt <[EMAIL PROTECTED]> wrote:
> Hi again,
>
> By acciden
16 matches
Mail list logo
