There was yet another similar discussion a half-year ago: http://markmail.org/thread/ap6v46r3mdsgdszp
------------------------------------------------------------------------------------------- Yu-Heng (Ryan) Lei, Associate Researcher Cloud Computing Dept, Chunghwa Telecom Labs ryan...@cht.com.tw or ryanlei750...@gmail.com On Tue, Jan 7, 2014 at 7:34 AM, Chiradeep Vittal < chiradeep.vit...@citrix.com> wrote: > Yes, there was another discussion here: > http://markmail.org/thread/uf6bxab6u4z4fmrp > > > > On 1/6/14 3:18 PM, "Kelven Yang" <kelven.y...@citrix.com> wrote: > > >Java 7 has been around for some time now. I strongly suggest CloudStack > >to adopt Java 7 as early as possible, the reason I feel like to raise the > >issue is from the some of practicing with the new DB transaction pattern, > >as following example shows. The new Transaction pattern uses anonymous > >class to beautify the code structure, but in the mean time, it will > >introduce a couple runtime costs > > > > 1. Anonymous class introduces a ³captured context², information > >exchange between the containing context and the anonymous class > >implementation context has either to go through with mutable passed-in > >parameter or returned result object, in the following example, without > >changing basic Transaction framework, I have to exchange through returned > >result with an un-typed array. This has a few implications at run time, > >basically with each call of the method, it will generate two objects to > >the heap. Depends on how frequently the involved method will be called, > >it may introduce quite a burden to java GC process > > 2. Anonymous class captured context also means that there will be more > >hidden classes be generated, since each appearance of the anonymous class > >implementation will have a distance copy of its own as hidden class, it > >will generally increase our permanent heap usage, which is already pretty > >huge with current CloudStack code base. > > > >Java 7 has a language level support to address the issues in a cheaper > >way that our current DB Transaction code pattern is trying to solve. > > > http://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClo > >se.html. So, time to adopt Java 7? > > > > public Outcome<VirtualMachine> startVmThroughJobQueue(final String > >vmUuid, > > final Map<VirtualMachineProfile.Param, Object> params, > > final DeploymentPlan planToDeploy) { > > > > final CallContext context = CallContext.current(); > > final User callingUser = context.getCallingUser(); > > final Account callingAccount = context.getCallingAccount(); > > > > final VMInstanceVO vm = _vmDao.findByUuid(vmUuid); > > > > > > Object[] result = Transaction.execute(new > >TransactionCallback<Object[]>() { > > @Override > > public Object[] doInTransaction(TransactionStatus status) { > > VmWorkJobVO workJob = null; > > > > _vmDao.lockRow(vm.getId(), true); > > List<VmWorkJobVO> pendingWorkJobs = > >_workJobDao.listPendingWorkJobs(VirtualMachine.Type.Instance, > > vm.getId(), VmWorkStart.class.getName()); > > > > if (pendingWorkJobs.size() > 0) { > > assert (pendingWorkJobs.size() == 1); > > workJob = pendingWorkJobs.get(0); > > } else { > > workJob = new VmWorkJobVO(context.getContextId()); > > > > > >workJob.setDispatcher(VmWorkConstants.VM_WORK_JOB_DISPATCHER); > > workJob.setCmd(VmWorkStart.class.getName()); > > > > workJob.setAccountId(callingAccount.getId()); > > workJob.setUserId(callingUser.getId()); > > workJob.setStep(VmWorkJobVO.Step.Starting); > > workJob.setVmType(vm.getType()); > > workJob.setVmInstanceId(vm.getId()); > > > >workJob.setRelated(AsyncJobExecutionContext.getOriginJobContextId()); > > > > // save work context info (there are some duplications) > > VmWorkStart workInfo = new > >VmWorkStart(callingUser.getId(), callingAccount.getId(), vm.getId(), > >VirtualMachineManagerImpl.VM_WORK_JOB_HANDLER); > > workInfo.setPlan(planToDeploy); > > workInfo.setParams(params); > > workJob.setCmdInfo(VmWorkSerializer.serialize(workInfo)); > > > > _jobMgr.submitAsyncJob(workJob, > >VmWorkConstants.VM_WORK_QUEUE, vm.getId()); > > } > > > > return new Object[] {workJob, new Long(workJob.getId())}; > > } > > }); > > > > final long jobId = (Long)result[1]; > > AsyncJobExecutionContext.getCurrentExecutionContext().joinJob(jobId); > > > > return new VmStateSyncOutcome((VmWorkJobVO)result[0], > > VirtualMachine.PowerState.PowerOn, vm.getId(), null); > > } > > > > > >Kelven > >
