Craig Russell commented on OPENJPA-160:

>K... IMO, we should get rid of the finalizer in the default config, and create 
>a new FinalizingBrokerImpl that has a finalizer, that can optionally be used 
>by developers. I think that we should make that the default, and then let 
>appserver providers (who are the most likely to definitely control resources 
>correctly) turn the finalization off.

Two comments, one procedural.

1. I really think we're going just a bit too fast here. I wasn't able to 
comment on the discussion because I've been in meetings all morning, and it's 
really tough to find the issue resolved, a patch committed, and I never had a 
chance. I also notice that just minutes after the commit, Abe had a comment 
that resulted in another change. For issues that attract this kind of 
attention, I think a little more time is probably needed to reach closure.

2. I'd like to reopen the discussion of which BrokerImpl should be the default. 
In general, I like performance options to be the default. It makes the "out of 
the box" experience better because users don't need to find, much less read, 
the relevant part of the documentation. Well-behaved applications don't need 
the finalizer. Small applications running in short-lived vms don't need it. 

So it seems the finalizer is only really needed in long-lived vms (application 
servers, web servers) that have poorly designed applications. Why is this the 
default? Applications that don't close their ems should be slapped about the 
upper body. Seems that the finalize method should do some strenuous logging 
(WARNING or SEVERE) to point out to the developer that they need to change 
their ways. 

Bottom line, I guess I'd prefer that the finalizer version be documented in the 
troubleshooting section of the doc.

> Reuse BrokerImpl objects
> ------------------------
>                 Key: OPENJPA-160
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-160
>             Project: OpenJPA
>          Issue Type: Sub-task
>            Reporter: Michael Dick
>         Assigned To: Patrick Linskey
>         Attachments: newprofile.jpg, openjpa-160-clone-patch.txt, 
> openjpa-160-finalization-and-cloning-patch.txt, openjpa-160-patch.txt, 
> openjpa-160-patch.txt, openjpa-160-patch.txt, openjpa-160-patch.txt, 
> perf2.jpg, perf3.jpg, profile_clonepatch.jpg, profile_explicitclass.jpg

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

Reply via email to