HiberHQ TODO

[jtravis_hyperic]

Gang,

I want to enumerate the things that we need to take care of before we
move on to our respective 3.0 assignments. Here are a few things
that I think are pretty important to take care of now:

1 - Our IDs are not incrementing by 1. Also, Hibernate is querying
for the nextval for every object that's inserted into the DB. This
is not crucial, but we should look at it now as it's a very low-level
framework decision.

2 - Need to make PersistedObject.setId() protected. I've taken care
of this.

3 - The resource group code is deleting and inserting a ton of values
into the table. This indicates we've either gotten something wrong
with the mapping, or we're returning the non-proxied collection to
Hibernate. Regardless, all these inserts/removals is very bad.

It would be nice if we could remove entity beans entirely from the
app, but I won't put that on the list.

Anything else that I'm missing?

-- Jon

[jtravis_hyperic]

Add to the list:

- Convert all the RT direct SQL

Remove from the list: #3

-- Jon




On Nov 2, 2006, at 1:30 PM, Jon Travis wrote:

> Gang,
>
> I want to enumerate the things that we need to take care of before
> we move on to our respective 3.0 assignments. Here are a few
> things that I think are pretty important to take care of now:
>
> 1 - Our IDs are not incrementing by 1. Also, Hibernate is querying
> for the nextval for every object that's inserted into the DB. This
> is not crucial, but we should look at it now as it's a very low-
> level framework decision.
>
> 2 - Need to make PersistedObject.setId() protected. I've taken
> care of this.
>
> 3 - The resource group code is deleting and inserting a ton of
> values into the table. This indicates we've either gotten
> something wrong with the mapping, or we're returning the non-
> proxied collection to Hibernate. Regardless, all these inserts/
> removals is very bad.
>
> It would be nice if we could remove entity beans entirely from the
> app, but I won't put that on the list.
>
> Anything else that I'm missing?
>
> -- Jon
>

[jtravis_hyperic]

I'd also like to have us using transaction=requires for pretty much
everything, as that was one of the major goals of doing the hibernate
conversion. We want everything to execute in a single transaction --
corrupt tables shouldn't be something we should ever have to think
about.

If there are instances where this is not working, we need to find out
why, and fix it.

-- Jon



On Nov 2, 2006, at 4:40 PM, Jon Travis wrote:

> Add to the list:
>
> - Convert all the RT direct SQL
>
> Remove from the list: #3
>
> -- Jon
>
>
>
>
> On Nov 2, 2006, at 1:30 PM, Jon Travis wrote:
>
>> Gang,
>>
>> I want to enumerate the things that we need to take care of before
>> we move on to our respective 3.0 assignments. Here are a few
>> things that I think are pretty important to take care of now:
>>
>> 1 - Our IDs are not incrementing by 1. Also, Hibernate is
>> querying for the nextval for every object that's inserted into the
>> DB. This is not crucial, but we should look at it now as it's a
>> very low-level framework decision.
>>
>> 2 - Need to make PersistedObject.setId() protected. I've taken
>> care of this.
>>
>> 3 - The resource group code is deleting and inserting a ton of
>> values into the table. This indicates we've either gotten
>> something wrong with the mapping, or we're returning the non-
>> proxied collection to Hibernate. Regardless, all these inserts/
>> removals is very bad.
>>
>> It would be nice if we could remove entity beans entirely from the
>> app, but I won't put that on the list.
>>
>> Anything else that I'm missing?
>>
>> -- Jon
>>
>

[admin]

transaction=REQUIRED 🙂

The problems will most like surface with areas where we queue up
actions that are performed when something is created. So for a
resource creation, we send a JMS message to get metrics enabled,
alert definitions applied, etc. So, before we send the message we
have to make sure that the transaction has ended and the resources
have been created. Now, I agree that we should probably re-architect
this with some other mechanism rather than a JMS message, but
clearing out the REQUIRESNEW right now will require us to put the
work into the re-architecture.

Charles

[jtravis_hyperic]

There are a lot of places where we haven't changed the transaction
type correctly. We should at least make an effort to go through all
the public APIs and make sure that they are the transaction scope
that we think is correct.

If we can't get them all, that's fine, but we should at least give it
a pass.

-- Jon



On Nov 2, 2006, at 7:45 PM, Charles wrote:

> transaction=REQUIRED 🙂
>
> The problems will most like surface with areas where we queue up
> actions that are performed when something is created. So for a
> resource creation, we send a JMS message to get metrics enabled,
> alert definitions applied, etc. So, before we send the message we
> have to make sure that the transaction has ended and the resources
> have been created. Now, I agree that we should probably re-
> architect this with some other mechanism rather than a JMS message,
> but clearing out the REQUIRESNEW right now will require us to put
> the work into the re-architecture.
>
> Charles
>