continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <br...@apache.org>
Subject Re: [discuss] iBatis, JPA and Java 5.0
Date Thu, 04 Jan 2007 02:36:43 GMT

On 03/01/2007, at 4:29 PM, Rahul Thakur wrote:

> I am not sure what you refer to by:
> [snip]
> The way Continuum is designed means
>> you get to a certain point where you want to save an object and  
>> you find that you can't, or you aren't saving everything you want,  
>> etc.
> [/snip]
>
> Could you please give an example?

Probably stretching my memory a bit too much for specific examples.  
ISTR there being worse things, but even looking at the  
DefaultBuildController there are a few ugly things.

In particular, storing build results, then having to get them back  
because they are going to be used again.

I think the transactions aren't long enough. It's possible to do  
things like:

doSomething
saveSomething
throw an exception
didn't get to save something else, so something is in a 'partial' state.

This is a continuum design issue, and if it were fixed the store  
would be simpler because you wouldn't need to be constantly updating/ 
storing/getting objects if they are still in the same open  
transaction that will either be committed or rolled back when it is  
done.

But bear in mind this is more my general impression than careful  
analysis :)

It was definitely the build results, the build number and the build  
state that I felt wasn't managed carefully enough.

- Brett

Mime
View raw message